Systems and methods for determining metrics of machines providing services to requesting clients

ABSTRACT

In one embodiment, a method for determining metrics of a content delivery and global traffic management network provides service metric probes that determine the service availability and metric measurements of types of services provided by a content delivery machine. A server in the network has a metric test associated with each service supported by the server which the service metric probes periodically performs metric tests on and records the metric test results which are periodically sent to all of the DNS servers in the network. Generic load probes also report metric test results. DNS servers use the test result updates to determine the best server to return for a given DNS name.

CROSS-REFERENCE TO RELATED APPLICATIONS Benefit Claim

The present application is a continuation of U.S. patent applicationSer. No. 13/419,723, filed Mar. 14, 2012, now U.S. Pat. No. 8,341,297which is a continuation of U.S. patent application Ser. No. 12/986,055,filed Jan. 6, 2011, now U.S. Pat. No. 8,195,831, which is a continuationof U.S. patent application Ser. No. 12/426,952, filed Apr. 20, 2009, nowU.S. Pat. No. 7,912,978, which is a continuation of U.S. patentapplication Ser. No. 09/909,711, filed Jul. 19, 2001, now U.S. Pat. No.7,523,181, which is a continuation in-part of U.S. patent applicationSer. No. 09/641,746 filed Aug. 18, 2000, now U.S. Pat. No. 6,484,143,and claims priority to and incorporates by reference for all purposes,Provisional U.S. Patent Application Nos. 60/219,172, 60/219,166,60/219,946, and 60/219,177 all filed on Jul. 19, 2000, and incorporatesby reference the teachings of U.S. patent application Ser. No.09/644,927 filed Aug. 23, 2000, now U.S. Pat. No. 6,405,252. Theteachings of all of the foregoing patents and patent applications arehereby incorporated by reference in their entireties.

The applicants hereby rescind any disclaimer of claim scope in theparent applications or the prosecution history thereof and advise theUSPTO that the claims in this application may be broader than any claimin the parent applications.

BACKGROUND OF THE INVENTION

1. Technical Field

The invention relates to world wide area networking in a computerenvironment. More particularly, the invention relates to deliveringcontent and managing traffic across a world wide area network in acomputer environment.

2. Description of the Prior Art

The Internet is a world wide “super-network” which connects togethermillions of individual computer networks and computers. The Internet isgenerally not a single entity. It is an extremely diffuse and complexsystem over where no single entity has complete authority or control.Although the Internet is widely know for one of its ways of presentinginformation through the World Wide Web (herein “Web”), there are manyother services currently available based upon the general Internetprotocols and infrastructure.

The Web is often easy to use for people inexperienced with computers.Information on the Web often is presented on “pages” of graphics andtext that contain “links” to other pages either within the same set ofdata files (i.e., Web site) or within data files located on othercomputer networks. Users often access information on the Web using a“browser” program such as one made by Netscape CommunicationsCorporation (now America Online, Inc.) of Mountain View, Calif. orExplorer™ from Microsoft Corporation of Redmond, Wash. Browser programscan process information from Web sites and display the information usinggraphics, text, sound, and animation. Accordingly, the Web has become apopular medium for advertising goods and services directly to consumers.

As time progressed, usage of the Internet has exploded. There areliterally millions of users on the Internet. Usage of the Internet isincreasing daily and will eventually be in the billions of users. Asusage increases so does traffic on the Internet. Traffic generallyrefers to the transfer of information from a Web site at a servercomputer to a user at a client computer. The traffic generally travelsthrough the world wide network of computers using a packetizedcommunication protocol, such as TCP/IP. Tiny packets of informationtravel from the server computer through the network to the clientcomputer. Like automobiles during “rush hour” on Highway 101 in SiliconValley, the tiny packets of information traveling through the Internetbecome congested. Here, traffic jams which cause a delay in theinformation from the server to the client occur during high usage hourson the Internet. These traffic jams lead to long wait times at theclient location. Here, a user of the client computer may wait for a longtime for a graphical object to load onto his/her computer.

From the above, it is seen that an improved way to transfer informationover a network is highly desirable.

It would be advantageous to provide a method for determining metrics ofa content delivery and global traffic management network that providesDNS servers useful information to effectively load balance and selectthe proper content servers for clients. It would further be advantageousto provide a method for determining metrics of a content delivery andglobal traffic management network that performs metric measurements in areliable manner.

SUMMARY OF THE INVENTION

The invention provides a method for determining metrics of a contentdelivery and global traffic management network. The system provides DNSservers useful information to effectively perform load balancing. Inaddition, the invention provides performance metrics that allow DNSservers to select the proper content servers for clients.

A preferred embodiment of the invention provides service metric probesthat determine the service availability and metric measurements of typesof services provided by a content delivery machine. Latency probes arealso provided for determining the latency of various servers within anetwork.

Service metric probes consult a configuration file containing each DNSname in its area and the set of services such as HTTP, HTTPS, FTP,streaming media, and/or generic SNMP associated with each DNS name. Eachserver in the network has a metric test associated with each servicesupported by the server.

The service metric probe periodically performs metric tests on theservers within its area and records the metric test results. Metric testresult updates are periodically sent to all of the DNS servers in thenetwork that consists of all tests since the last update. DNS serversuse the test result updates to determine the best server to return for agiven DNS name.

The service metric probe can also send a packet request to a server andwill receive a packet containing the various metrics of the server. Itthen combines the server metrics to arrive at a load metric which issent to the DNS servers.

The latency probe calculates the latency from its location to a client'slocation. It calculates the round trip time for sending a packet to aclient to obtain the latency value for that client. The round trip timetests that the latency probe performs, includes: PING, UDP Reverse Namelookup, and/or UDP Packets to high number ports. The latency probeupdates the DNS servers with the clients' latency data.

When the latency probe sends a UDP Packet probe to high number portsthat fails, it resends the UDP Packet probe starting with a low TTLnumber and increments the TTL until failure occurs. The last successfulTTL value indicates the partial latency data.

The DNS server uses the latency test data updates to determine theclosest server to a client.

Other aspects and advantages of the invention will become apparent fromthe following detailed description in combination with the accompanyingdrawings, illustrating, by way of example, the principles of theinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified diagram of a system according to an embodiment ofthe present invention;

FIG. 2 is a more detailed diagram of probes used in the system accordingto an embodiment of the present invention;

FIG. 3 is a more detailed diagram of a caching sequence used in thesystem according to an embodiment of the present invention;

FIG. 4 is a simplified flow diagrams of methods according to embodimentsof the present invention;

FIG. 4A is a simplified system diagram according to an embodiment of thepresent invention;

FIGS. 5A to 5H are simplified diagrams of content delivery networkaccording to an embodiment of the present invention;

FIGS. 6A to 6E are simplified diagrams of global traffic managementsystem according to an embodiment of the present invention;

FIG. 7 is a block schematic diagram showing the interaction between theSpeedera DNS Server (SPD) and other components according to theinvention;

FIG. 8 is a block schematic diagram showing a POP Speedera network withthe invention's software components distributed among POP servers andNetwork Operations Centers according to the invention;

FIG. 9 is a block schematic diagram showing the interaction betweensoftware components of the invention according to the invention;

FIG. 10 is a block schematic diagram showing the exchange of databetween Latency Probes, Service Probes and other servers within anetwork according to the invention; and

FIG. 11 is a block schematic diagram showing the processes and exchangeof data between logging server components according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention is embodied in a method for determining metrics of acontent delivery and global traffic management network in a computerenvironment. A system according to the invention provides DNS serversuseful information to effectively perform load balancing. In addition,the invention provides performance metrics that allow DNS servers toselect the proper content servers for clients.

According to the present invention, a technique including a userinterface device and system for global traffic management and contentdistribution is provided. In an exemplary embodiment, the method isapplied to a world wide network of computers, such as the Internet or aninternet.

In a specific embodiment, the invention provides a user interface deviceand system for providing a shared GTM and CDN (collectively UniversalDistribution Network) for a service fee, where the customer or user doesnot need to purchase significant hardware and/or software features. Thepresent interface device and system allows a customer to scale up itsWeb site, without a need for expensive and difficult to use hardwareand/or software. In a preferred embodiment, the customer merely pays fora service fee, which can be fixed, variable, lump some, or based upon asubscription model using the present system. The present device andsystem are preferably implemented on a system including a novelcombination of global traffic management and content distribution.

An overall system diagram 100 is illustrated in FIG. 1. The diagram ismerely an example, which should not unduly limit the scope of the claimsherein. One of ordinary skill in the art would recognize many othervariations, modifications, and alternatives. As shown, the system 100includes a variety of features to defined the Universal Delivery Network(UDN). The UDN has a combined content delivery network 103 and 104 and aglobal traffic management network 105, which are coupled to each other.This eliminates the need for independent CDN and GTM solutions. The UDNcan be implemented as a single outsourced solution or service to acustomer. When deployed across the WAN, it creates a unified networkthat provides a universal solution for content routing and highavailability delivery.

Customers can leverage the size, scope, and location of the UDN to storecontent such as HTML, images, video, sound and software for fast andhighly available access by clients. The network can also incorporatecustomer origin sites 107, 109 that will then benefit from shared loadbalancing and traffic management. Customers with generated content, suchas search engines, auctions and shopping carts, can use the latterfeature to add their own content servers to the network. In someembodiments, the system typically requires no software or hardware to beinstalled or run at a customer site. A Web interface is available fordisplay of the network's current status as well as historical statisticson a per customer basis.

The system functions by mapping hostnames, such as www.customer.com to acustomers origin servers 107 and 109. The local DNS 113 queries thetraffic management system 105 for name resolution of the customers Website and receives a response specifying the server best suited to handlethe request, either customer origin servers 107 or servers 103 locatedin the UDN. When the client 111 requests a customer homepage, tagswithin the HTML direct the imbedded static content to the network ofcache servers 103 and 104. In this example the static content may betagged with a domain name like customer.speedera.com. Each local DNS inthe example is directed to a different resource for each hostname basedon several factors, such as proximity to the resource, networkcongestion, and server load.

In this example, www.customer.com is mapped to the customer originservers represented by customer origin Sites 1 109 and 2 107.Customer.speedera.net is mapped to a collection of delivery nodesrepresented by point of presence servers, i.e., POPs 103, 104. As merelyan example, a method for using such a UDN is provided below.

1. The client 111 requests a customer home page: www.customer.com from alocal DNS 113.

2. The local DNS 113 queries the traffic management system 105 for nameand address resolution and receives a reply 125, 127 indicating theoptimal customer origin site to retrieve the homepage 131. In this step,the traffic management system still looks at many if not all factors;network health, server health, packet loss, cost, etc. to determine theoptimal customer origin site.

3. The client connects to the site and retrieves the home page (solidblue line) 123, 121.

4. An object with the image tag specifyinghttp://customer.speedera.net/www.customer.com/hello.gif is found in theHTML of the homepage.

5. The local DNS queries the traffic management system for name andaddress resolution.

6. The traffic management system looks 129, 131 at factors such asnetwork performance and server load and returns the address of the POPbest suited to serve the requested content.

7. The client then retrieves the content from the specified deliverynode 117, 119.

This sequence of steps is merely illustrative. The steps can beperformed using computer software or hardware or a combination ofhardware and software. Any of the above steps can also be separated orbe combined, depending upon the embodiment. In some cases, the steps canalso be changed in order without limiting the scope of the inventionclaimed herein. One of ordinary skill in the art would recognize manyother variations, modifications, and alternatives. Details of each ofthe features noted above are more fully described below.

The DNS server (DNS) can be thought of as the traffic director of thesystem. It contains a mapping of where resources (grouped by hostnames)have been allocated as well as the current state of each resource andtheir availability to each client. It receives the static information(the mappings) from the configuration file and the dynamic information(resource availability) from the probes. The configuration file alsoinstructs the DNS server how to weight the various criteria availablewhen making its decisions. The DNS is a fully functional DNS server andis compatible with current versions of BIND. Decision criteria coversuch areas as resource availability, resource load, latency, staticmapping configuration, persistence requirements, fail over logic,weighting parameters, and others, each of which can be alone orcombined.

Multiple DNS servers are deployed to provided high availability. The DNSservers are spread throughout the network to avoid single points offailure. The DNS server was designed from the beginning with the abilityto proxy requests. This proxy ability combined with algorithms to divideclient latency and persistence information across a group of DNS serversgreatly reduces the problems associated with WAN replication andsynchronization. In the event a request arrives at a DNS server that isnot authoritative for this client, the DNS can proxy the request to anynumber of servers to find an authoritative answer.

The DNS server logs both request and operational data to the databasefor subsequent viewing. Both real-time and historical views areavailable. The request data allows the administrator and customer to seeto the number of requests directed to each POP on a per hostname basis.The operational data provides statistics about the DNS server and wouldtypically only be viewed by the administrator.

The present system also uses one or more probes to detect informationabout certain criteria from the network. There are probes including aNetProbes, a ServiceProbe and a LatencyProbe. ServiceProbes test localserver resources while LatencyProbes conduct network round trip tests toclients. Each POP in the network is assigned a ServiceProbe and aLatencyProbe—these can be separate machines but in most cases, the samemachine will perform both types of probe.

The NetProbes are responsible for providing the traffic managementsystem with service and latency metrics. The metrics are reported to theDNS server and LogServers. FIG. 2 is a simplified diagram 200 of theseprobes according to embodiments of the present invention. This diagramis merely an example which should not limit the scope of the claimsherein. One of ordinary skill in the art would recognize manyvariations, alternatives, and modifications. The diagram 200 includes aPOP 201, which includes a NetProbes server. Service probes monitor thePOP servers to test the availability and load of the services theysupport. The latency probe tests the round trip time between the POP andthe DNS servers.

A ServiceProbe determines service metric information for servers in theUDN and reports them to the DNS server. Service metrics are one of thedecision criteria used by the DNS to make its routing determinations.Each server in the UDN supports one or more services—a Web serverprovides HTTP service, a FTP server provides FTP service. The serviceprobe uses various approaches for gathering data—a service test andstatistical monitoring. The value of a service metric is dependent onthe metric type and it's implementation.

The HTTP service is an example of the service test approach. Rather thentry to test the individual characteristics of a server that may have animpact on performance, the service itself is evaluated as a user wouldexperience it, in order to determine its response time and validity.LOADP, a process running on each server, is implemented as a statisticalmonitor and is used as a generic service for testing purposes. LOADPprovides direct measurement of many system parameters including CPUload, memory usage, swap and disk status, and is used in load balancingdecisions.

Hostnames in the system are mapped to service types. This allows a givenserver to support multiple services and be evaluated independently foreach of them. When a request for a particular hostname arrives at a DNS,the service associated with that hostname is compared on each of themachines to find the best-suited server. The data from the probes aresent to both the DNS as well as the database. By sending the data to thedatabase, it allows the performance of the network to be viewed in realtime as well as over a period of time.

Every server in the UDN is housed in a POP and each POP has a LatencyProbe assigned to it, as shown. The Latency Probes determine the latencyfrom their location to other locations on the Internet (specifically toclient DNS' requesting name resolution). The DNS' use this informationin determining the best-suited server for a particular request. The listof locations that are used in order to determine the latency is drivenby the DNS. When it is determined by a DNS server that its currentinformation regarding latency between “x” number of POPs and a client'slocal DNS has become stale, it will instruct the probe for thatparticular POP to recalculate the latency.

The probes utilize a collection of methods to determine the latencybased on cost. The probe uses the least expensive method first and moveson to more expensive methods if no results are determined. The probe isdesigned so new methods can be plugged in as they are developed. Themethods can be either active or passive and are prioritized based onaccuracy. Active methods may take the form of ping or traceroute but aretypically more sophisticated. Passive methods could reference local BGPtables to determine cost metrics.

The individual latency data is sent to the DNS servers while operationaldata of each method, their success rates, etc are sent to the database.This allows the current and new methods to be monitored and managed.LatencyProbes perform latency tests to the local client DNS (LDNS). TheLatencyProbes build a table of LDNS' to test over time, receiving thelist of which DNS client IP addresses to probe from the DNS Servers inthe network.

In a specific embodiment, the delivery nodes are the edge deliveryservers of the network. The invention can support any types of IP baseddelivery servers including but not limited to HTTP. SSL, FTP, Streaming,NNTP, and DNS servers. In preferred embodiments, the invention uses anHTTP server and SSL cache server. The HTTP and SSL servers are identicalwith the exception of the encryption used on the data to and from theSSL cache in some embodiments. These servers have a proxy component thatallows them to fill their cache by making requests to an origin site ifa requested object is not in the cache. A method according to theinvention can be briefly described as follows in reference to thesimplified diagram 300 of FIG. 3:

1. An initial user makes a request to the cache for an objecthttp://customer.speedera.net/www.cutomer.com/images/test.gif (Step 1);

2. The cache, discovering that it does not have the object, will findthe name of the origin site in the URL (www.customer.com) and make arequest to the origin site for /images/test.gif (Step 2);

3. When the cache receives the object it is saved on disk and memory andreturned to the initial user. Subsequent users who make requests for thesame object will be satisfied by the cache directly (Step 3).

This sequence of steps is merely illustrative. The steps can beperformed using computer software or hardware or a combination ofhardware and software. Any of the above steps can also be separated orbe combined, depending upon the embodiment. In some cases, the steps canalso be changed in order without limiting the scope of the inventionclaimed herein. One of ordinary skill in the art would recognize manyother variations, modifications, and alternatives.

Other protocols will work in a similar fashion unless there is a timeconcern with loading the first request. An example of this is a livestreaming event or large file downloads (patches or video on demand). Inthese cases the caches may be pre-filled with the data that they need toserve. This pre-filling may take place over terrestrial lines or viasatellite in some cases. Statistics about data delivered from thedelivery nodes are reported through the logging system to the databasefor subsequent viewing and analysis.

The system also has a user interface. Here, engineering staff as well ascustomers can login to monitor and administer the network access fromnearly any Internet connected Web browser (with proper authentication).The user interface includes tables and graphs from the database. Dataarrives at the user interface through the Logging System. This systemhas two parts: Log Distributor daemons and Log Collector daemons. Thisdaemon monitors a defined directory for completed log files. Log filesare defined as complete when they reach a defined size or age. A loggingAPI which all resources share controls the definitions of size and age.When the Log Distributor finds completed log files it is able to sendthem back to one of many Log Collector daemons for insertion in thedatabase.

As noted, the present network has many advantages. The network has ascomprehensive, extensible, multi-faceted global traffic managementsystem as its core, which is coupled to a content delivery network.Further details of the present content delivery network and globaltraffic management device are provided below. According to the presentinvention, a method for providing service to customers is provided.Details of such service are provided below.

FIG. 4 is a simplified flow diagram of a novel service method 400according to an embodiment of the present invention. The diagram ismerely an example, which should not unduly limit the scope of the claimsherein. One of ordinary skill in the art would recognize many othervariations, modifications, and alternatives. As shown, the method beginsat start, step 401. The method connects (step 403) a client to a serverlocation through a world wide network of computers. The world widenetwork of computers can include an internet, the Internet, and others.The connection occurs via a common protocol such as TCP/IP. The clientlocation is coupled to a server, which is for a specific user. The usercan be any Web site or the like that distributes content over thenetwork. As merely an example, the user can be a portal such as Yahoo!Inc. Alternatively, the user can be an electronic commerce site such asAmazon.com and others. Further, the user can be a health site.Information sites include the U.S. Patent Office Web site, educationalsites, financial sites, adult entertainment sites, service sites,business to business commerce sites, etc. There are many other types ofusers that desire to have content distributed in an efficient manner.

In a specific embodiment, the user registers its site on the server,which is coupled to a content distribution server coupled to a globaltraffic management server. The user registers to select (step 407) aservice from the server. The service can be either a traffic managementservice (step 414) or a traffic management service and contentdistribution service (step 411). Depending upon the embodiment, the usercan select either one and does not need to purchase the capitalequipment required for either service. Here, the user merely registersfor the service and pays a service fee. The service fee can be basedupon a periodic time frequency or other parameter, such as performance,etc. Once the service has been requested, the user performs some of thesteps noted herein to use the service.

Next, the method processes (step 423) the user's request and allows theuser to use the content distribution network and/or global trafficmanagement network, where the user's Web pages are archives anddistributed through the content distribution network in the mannerindicated herein. The user's Web site should become more efficient fromthe use of such networks. Once a periodic time frequency or otherfrequency has lapsed (step 419), the method goes to an invoicing step,step 417. The invoicing step sends (step 427) an invoice to the user.Alternatively, the process continues until the periodic time frequencyfor the designated service lapses via line 422. The invoice can be sentvia U.S. mail, electronic mail, or the like. The method stops, step 425.Alternatively, the invoicing step can deduct monetary considerationthrough an electronic card, e.g., debit card, credit card.

This sequence of steps is merely illustrative. The steps can beperformed using computer software or hardware or a combination ofhardware and software. Any of the above steps can also be separated orbe combined, depending upon the embodiment. In some cases, the steps canalso be changed in order without limiting the scope of the inventionclaimed herein. One of ordinary skill in the art would recognize manyother variations, modifications, and alternatives. It is also understoodthat the examples and embodiments described herein are for illustrativepurposes only and that various modifications or changes in light thereofwill be suggested to persons skilled in the art and are to be includedwithin the spirit and purview of this application and scope of theappended claims.

FIG. 4A is a simplified diagram of a computing system 430 according toan embodiment of the present invention. This diagram is merely anexample which should not unduly limit the scope of the claims herein.One of ordinary skill in the art would recognize many other variations,modifications, and alternatives. Like reference numerals are used inthis FIG., as the previous FIG. for cross-referencing purposes only. Asshown, the computing system 430 carries out certain functionality thatis integrated into the method above as well as others. The computingsystem includes an accounting module 429, which carries out certainaccounting functions. The accounting module interfaces with mass memorystorage 431, a microprocessing device 433, and a network interfacedevice 435, which couples to local and/or wide area networks. The moduleoversees an invoicing step 417 and transfer step 427, as shown. Here,the accounting module is a task master for the service based method forusing the content delivery network and/or global traffic managementnetwork.

Before discussing the accounting module in detail, we begin an overallmethod at start, step 401. The method connects (step 403) a client to aserver location through a world wide network of computers. The worldwide network of computers can include an internet, the Internet, andothers. The connection occurs via a common protocol such as TCP/IP. Theclient location is coupled to a server, which is for a specific user.The user can be any Web site or the like that distributes content overthe network. As merely an example, the user can be a portal such asYahoo! Inc. Alternatively, the user can be an electronic commerce sitesuch as Amazon.com and others. Further, the user can be a health site.Information sites include the U.S. Patent Office Web site, educationalsites, financial sites, adult entertainment sites, service sites,business to business commerce sites, etc. There are many other types ofusers that desire to have content distributed in an efficient manner.

In a specific embodiment, the user registers its site on the server,which is coupled to a content distribution server coupled to a globaltraffic management server. The user registers to select (step 407) aservice from the server. The service can be either a traffic managementservice (step 414) or a traffic management service and contentdistribution service (step 411). Depending upon the embodiment, the usercan select either one and does not need to purchase the capitalequipment required for either service. Here, the user merely registersfor the service and pays a service fee. The service fee can be basedupon a periodic time frequency or other parameter, such as performance,etc. Additionally, the user enters information such as the user's domainname, physical address, contact name, billing and invoicinginstructions, and the like. Once the service has been requested, theuser performs some of the steps noted herein to use the service.

Next, the method processes (step 423) the user's request and allows theuser to use the content distribution network and/or global trafficmanagement network, where the user's Web pages are archives anddistributed through the content distribution network in the mannerindicated herein. The user's Web site should become more efficient fromthe use of such networks. Once a periodic time frequency or otherfrequency has lapsed (step 419), the method goes to an invoicing step,step 417. Here, the method accesses the accounting module, which canretrieve registration information about the user, service terms,invoices, accounts receivables, and other information, but is notlimited to this information. The accounting module determines theservice terms for the user, which has already registered. Once theservice terms have been uncovered from memory, the module determines theway the user would like its invoice. The accounting module directs aninvoicing step, which sends (step 427) an invoice to the user.Alternatively, the process continues until the periodic time frequencyfor the designated service lapses via line 422. The invoice can be sentvia U.S. mail, electronic mail, or the like. The method stops, step 425.Alternatively, the invoicing step can deduct monetary considerationthrough an electronic card, e.g., debit card, credit card. To finalizethe transaction, an electronic mail message can be sent to the user,which is logged in memory of the accounting module.

This sequence of steps is merely illustrative. The steps can beperformed using computer software or hardware or a combination ofhardware and software. Any of the above steps can also be separated orbe combined, depending upon the embodiment. In some cases, the steps canalso be changed in order without limiting the scope of the inventionclaimed herein. One of ordinary skill in the art would recognize manyother variations, modifications, and alternatives. It is also understoodthat the examples and embodiments described herein are for illustrativepurposes only and that various modifications or changes in light thereofwill be suggested to persons skilled in the art and are to be includedwithin the spirit and purview of this application and scope of theappended claims.

EXAMPLE

To prove the principle and operation of the present invention, we haveprovided examples of a user's experience using the present invention.These examples are merely for illustration and should not unduly limitthe scope of the claims herein. One of ordinary skill in the art wouldrecognize many other variations, modifications, and alternatives. Foreasy reading, we have provided a description for a user's experience ofa content delivery network and a user's experience of a global trafficmanagement service, which is coupled to such content delivery network.

Content Delivery Network

1. Overview

In a specific embodiment, the invention provides a content distributionnetwork. The following description contains information on how to use agraphical user interface to monitor activity, control cache, and performchecks. In some embodiments, the invention also provides a way forcustomer feedback to improve the service.

The present network is substantially always available in preferredembodiments. The network includes a Network Operations Center (NOC),which is dedicated to maintaining the highest possible networkavailability and performance. In most cases, the network is supportedand staffed by specially trained service engineers, the 24-hour, 7 dayNOC provides consultation, troubleshooting, and solutions for everyissue. The staff can be reached through telephone, email, fax, oronline. The staff generally connects you to engineers and solutions, notto answering machines.

In a specific embodiment, the network service can be used as long as theuser has certain desires. For example, the user has content that needsto be delivered to end-users. This content can be delivered throughHTTP, HTTPS, Streaming Media, or FTP, and the like. The server is forhosting the content on the Internet. For standard Web content, weimplemented a caching system to distribute Web content from an originserver to a cache server that is close to a user. This means an originserver needs to exist that contains a master copy of the content. If theuser has an existing Web site, the existing Web site will be the originsite.

In one embodiment, the present network is comprised of clusters ofservers at points of presence located on many different backbonenetworks around the world. The servers provide global traffic managementand distribution services for content of many kinds, including supportfor HTTP, HTTPS, FTP, and multiple varieties of streaming media.

In a specific embodiment, the present network includes one or moreservices. Here, the network may offer services, including:

1. Global Traffic Management—Provides global load balancing acrossmultiple origin sites, along with intelligent failover and otheradvanced capabilities such as persistence and static mapping.

2. Content Delivery Network (CDN)—Supports content distribution anddelivery for HTTP, HTTPS and FTP.

3. Streaming—Supports distribution and delivery of streaming media inmany formats, such as Real Media, Windows Media, QuickTime and others.

The present CDN service has some advantages. For example, the CDNservice helps increase the performance of any conventional Web site orother Internet services. It also helps reduce latency problems andpacket loss, and it provides for content synchronization andreplication. The network also reduces latency problems and packet loss.Latency problems result when the user's request travels beyond a certaindistance or makes a number of network hops. When users request contentfrom the Web or FTP sites, the requests are routed through the Internetto the server. If, as is true for many companies, the servers arelocated at only one site or a small number of sites, they will not beclose to most of the users. Therefore, the users' request for contentmight traverse many networks to communicate with the desired servers.

Latency problems are often aggravated by packet loss. Packet loss,common on the Internet, tends to worsen at “peering points,” locationswhere different networks connect. One way to reduce packet loss andlatency is to install content servers closer to users and ensure thatwhen a user requests data, the request is routed to the closestavailable server. The present network has deployed Web caches,streaming, and FTP servers throughout the Internet, on many networksclose to end users. In addition, the network uses a Global TrafficManager that routes traffic to the closest, most available and leastloaded server.

The network often synchronizes the content on the customer's origin sitewith the Web cache servers on the network. When new content is placed onan origin site and when users make requests for that content, it isautomatically replicated to Web cache servers in the network. When newcontent is published on the origin site with a new name, it is generallyimmediately available from all caches in the present network. Forexample, the network user might add an object to the site where asimilar object exists:

Add “www.customer.com/images/picture2.jpg” to the same site as“www.customer.com/images/picture.jpg.”

When a request for “picture2.jpg” arrives at a cache the first time, thecache in the network determines that it does not have a copy of“picture2.jpg”, and the cache will request a copy from the origin site.To keep in synchronization with the origin site, the caches periodicallycheck the content they have cached against the copy of the content inthe origin site. For Web content, this is accomplished by periodicallyperforming an “If-modified-since” request back to the origin site to seeif the content has changed. This causes content changed on the originsite to be refreshed on the caches at a predefined interval. Thisinterval can be configured depending upon ones needs.

The periodic checking is a common feature of caches but if a piece ofcontent is updated, the old content may be invalidated and the newcontent published to all the caches in the network. The present CDNservice makes this purging possible with a cache control utility thatallows you to invalidate a single object, a content directory, or anentire site contained in the caches. In a specific embodiment, cachecontrol is available as part of the service—a service provided to allcustomers. The present service method provides a comprehensive set ofmonitoring and administration capabilities for management of the Website.

In a specific embodiment, the present service method runs on a secureserver on the Internet and can be accessed only through a Web browserthat supports secure connections (SSL). A username and password areoften assigned to a user or customer when signed up for the service.

One of ordinary skill in the art would recognize many other variations,modifications, and alternatives. The above example is merely anillustration, which should not unduly limit the scope of the claimsherein. It is also understood that the examples and embodimentsdescribed herein are for illustrative purposes only and that variousmodifications or changes in light thereof will be suggested to personsskilled in the art and are to be included within the spirit and purviewof this application and scope of the appended claims.

2. Procedures

We now describe the procedures that can perform to set up the presentCDN service and to monitor the performance of the Web site:

-   A. Implementing the CDN;-   B. Invalidating content by controlling cache;-   C. Monitoring activity; and-   D. Performing tests.

Details of each of these procedures are provided below.

A. Implementing the CDN

To implement the CDN, the customer only need to make minor changes tothe Web pages in order to direct user requests to the present Web cachesinstead of to the origin site. In a specific embodiment, the method isas simple as changing the pointers in the HTML. When a cache gets arequest for content, it will return the requested object if it exists inthe cache. If the content does not exist, it will retrieve the contentfrom the origin site and return it to the user, as well as cache thecontent so that subsequent requests for that object are instantlyavailable.

To modify the site, the customer can either: (1) changing the URL; or(2) set up virtual hosting. In a specific embodiment, the site can bemodified for redirecting a user requests by changing the URL in theHTML. The following example, a request for a picture, shows the originalhtml and the revised html.

Original Homepage

The original homepage contains the following URL:

-   http://www.customer.com/page.html

The URL contains the following HTML:

-   <html><body>

Here is a picture:

-   <img src=“images/picture.jpg”>-   </body></html>

Revised Homepage

The “img src” tag has been revised:

-   <html><body>

Here is a picture:

-   <img    src=“http://customerspeedera.net/www.customer.com/images/picture.jpg”></body></html>

With the original configuration, a user's browser requests the picturefrom the customer.com Web servers:

-   page.html from www.customer.com-   images/picture.jpg from www.customer.com

With the revised configuration, a user's browser requests the picturefrom the customer.speedera.net Web servers:

-   page.html from www.customer.com-   www.customer.com/images/picture.jpg from customer.speedera.net

Note: If the cache does not hold the requested object in memory or ondisk, it makes a request to the origin site and caches it.

In an alternative embodiment, the method can set up virtual hosting sothat the user's request for content is directed to the present CDNinstead of to the origin site. Here, the customer can change the DNSsetup to cause the domain name to resolve to the present network cacheservers instead of to the original Web server. The domain name may bechanged, for example, change the domain name from www.customer.com towwx.customer.com. The present caches in the network can be configured ina way such that when they get a request for www.customer.com contentthey have not cached, they can make a request to the wwx.customer.comorigin site to get the content. Here, the URLs in the Web pages may notneed to be changed.

B. Invalidating Content by Controlling Cache

To invalidate the content contained in the caches, do the following:

-   1. Access the user interface at:-   https://speedeye.speedera.com-   2. Find the Cache Control page (see FIG. 5A) in the Content Delivery    section of the interface.-   3. Enter the URL in the text field.-   4. Click Submit.    For example, if an image:-   www.customer.com/images/picture.jpg    and the user changed the image without changing the name and the    user wanted the change to be immediately reflected in all caches in    the network, the user could use the present service to invalidate    the old content, as follows:

Enter “http://www.customer.com/images/picture.jpg” to invalidate theindividual picture, or “http://www.customer.com/images/” to invalidateall content in the images directory, or “http://www.customer.com” toinvalidate all content in the domain.

Note: Invalidating any of the above causes the change to “picture.jpg”to immediately be reflected in all the caches.

C. Monitoring Activity

In a specific embodiment, the present method allows the user to monitorthe operation of the Content Delivery Network service. The presentmethod shows how much content is being delivered and where it is beingdelivered. The start section of the user interface contains a table thatshows the present domains and associated origin domains your account isset up to use, as shown in FIG. 5B.

In a specific embodiment, the method includes monitoring recentactivity, as shown in FIG. 5C. Here, the user can view the current andlast 24 hours of content delivery traffic for a given domain:

-   1) Access the user interface at:-   https://speedeye.speedera.com-   2) Find the Recent Activity page in the Content Delivery section of    the interface.

As shown, the has more than one graphs. The first shows the amount oftraffic served by the content delivery network for that domain over thelast 24 hours. The current traffic is shown on the far right. A dottedvertical line separates data from yesterday on the left and data fromtoday on the right. A second graph on the same page (see FIG. 4) showsthe number of hits per second over the last 24 hours. The total numberof hits over the last 24-hour period is shown in the title bar of thegraph.

In an alternative embodiment, the method includes monitoring activity bylocation Here, the user views the last 24 hours of content deliverytraffic by location for a given domain:

-   1. Access the user interface at:-   https://speedeye.speedera.com-   2. Find the By Location page in the Content Delivery section of the    user interface.

A world map appears (see FIG. 5D) that shows all the locations thatserved traffic for the domain.

Below the world map is a bar graph (see FIG. 5E) that shows the amountof traffic served from each individual location over the last 24 hoursfor a given domain name. This graph is useful for many purposes, such asfor determining the optimal location for a second origin site—typically,at the location serving the most traffic, where there is not currentlyan origin site and when that location is on a different network than theexisting origin site.

D. Performing Tests

According to the present invention, selected tests can be performed tocheck performance, as follows:

-   1) Access the user interface at:-   https://speedeye.spedera.com-   2) Locate the Tests section.-   3) Select the test you want to perform.

A “page check” test can be performed. This test allows the user to checkthe performance of a Web page from multiple locations. To use the pagecheck program, do the following:

-   1) In the text field, enter the URL to test.-   2) Select the locations from which the user wants to check the page.-   3) Click Check.

At that point, servers at the location(s) selected will be contacted tohit the Web page associated with the URL entered and time how long ittakes to download the page and all its components. When the servers havecompleted downloading the page, the results are shown in the form oftables and graphs. The first table (see FIG. 5F) is the overallperformance table. It appears at the top of the results.

In this example, the page took an average of 500 milliseconds (half asecond) to download from the first three locations (rows) and 1317milliseconds (1.3 seconds) from the last location. A server name,physical location, and network location identify each location. Forexample, the last location in FIG. 5G is labeled as“server-14/sterling/exodus.” This label identifies a server on theExodus network located in Sterling, Va., USA.

After the overall timetable, details for each location are presented inindividual tables. FIG. 5H shows a table containing the details for thelocation “server-14, dc, cw,” a server located on the Cable & WirelessNetwork in Washington D.C., USA. The IP address of the actual server isshown in the heading of the table so you can perform additional tests,if needed, (traceroute and so on) on the actual server performing thetest.

The Location table in FIG. 5H shows data for the www.speedera.com Website. The graph shows the performance for downloading specificcomponents of the page. This table shows that the majority of the timespent in the download was spent downloading the home page itself. Theremainder of the content (all the gifs on the subsequent lines) has beencached and is delivered from the closest and least loaded availableserver within the CDN, in a fraction of the time. These cached itemshave a domain name of www.speedera.net.

In a specific embodiment, the colors in the graph show the differentcomponents of the download including the DNS lookup time, connect time,and so on. The first time a page is checked, the DNS times will likelybe very high. This high reading results from the way DNS works in theInternet. If a domain name is not accessed within a specific amount oftime (the timeout period), the information will expire out of the DNScaches. The first request will again need to walk through the Internet'shierarchical system of DNS servers to determine which one isauthoritative for a given domain name.

To get even more accurate results, a page can be hit twice, where theresults from the second hit are used. This will give a more accuraterepresentation of what the performance is like when the page is beinghit on a regular basis. The graph is followed by the actual raw datathat makes up the graph. Each row displays the following elements:

-   URL. The URL component downloaded-   IP Address. The IP address of the server contacted to get the data-   ERR. The error code (where 0 is no error)-   HRC. The HTTP response code (where 200 is OK)-   LEN. The length of the data downloaded-   CHK. A checksum of the data-   STT. The timing in milliseconds for the start time-   DRT. DNS response time in milliseconds-   COT. Connection Time—Syn/SynAck/Ack Time-   DST. Data start time when first packet is downloaded-   FNT. Final time when download is complete-   END. The total millisecond timings for portions of the connection    Global Traffic Manager

The present invention provides a global traffic manager. The globaltraffic manager is coupled to the content delivery network. Thefollowing provides a description of the global traffic manager. Thedescription is merely an illustration, which should not unduly limit theclaims herein. One of ordinary skill would recognize many othervariations, alternatives, and modifications.

1. Procedures

To use the Global Traffic Management service, the following will beused:

A. Domain name representing a service.

The domain name can be delegated for which the users are authoritativeso that the present servers are contacted to resolve the domain name toan IP address, or addresses. Alternatively, we can create a domain namefor you. That name will end with speedera.net, such ascustomer.speedera.net.

B. More that one IP address associated with that service.

Obtaining more that one IP address for a given service provides thefollowing benefits from the Global Traffic Management service:

Provides better service for clusters of servers on multiple networks. Ifa location within a cluster fails, or the network associated with thatlocation fails, the system can route traffic to another availablenetwork because there is more than one IP address. The system alsoprovides better performance by sending user requests to the closestcluster of servers. These routing options are not available if a localload balancer is used to manage the cluster, since a local load balancerrequires that each cluster of servers use a single IP address.

Provides better service for clusters of servers on a single network. Ifeach computer has a different IP address, the Global Traffic Managementservice can be used to load-balance between individual computers.

Reduces latency for a single cluster of servers that is attached tomultiple network feeds. In this configuration, the Global TrafficManagement can route around network failures by testing each of thenetwork connections and by routing user requests to the closest workingconnection.

In a specific embodiment, the present network is comprised of clustersof servers at points of presence located on many different backbonenetworks around the world. The servers provide global traffic managementand distribution services for content of many kinds, including supportfor HTTP, HTTPS, FTP, and multiple varieties of streaming media. Aspreviously noted, the services include: Global TrafficManagement—Provides global load balancing across multiple origin sites,along with intelligent failover and other advanced capabilities such aspersistence and static mapping; Content Delivery Network (CDN)—Supportscontent distribution and delivery for HTTP, HTTPS and FTP; andStreaming—Supports distribution and delivery of streaming media in manyformats, such as Real Media, Windows Media, QuickTime and others.

The present Global Traffic Management service routes user requests tothe closest available and least-loaded server. The service also teststhe servers it manages for service performance and availability, usingactual application-level sessions. When a service test fails, the systemreroutes the traffic to other available servers. The Global TrafficManagement service is based on Domain Name Service (DNS). The Internetuses the DNS to allow users to identify a service with which they wantto connect. For example, www.speedera.com identifies the Web service(www) from speedera.com.

When users request a service on the Internet, they request it by its DNSname. DNS names were created to make it easier for users to identifycomputers and services on the Internet. However, computers on theInternet do not communicate with each other by their DNS namesTherefore, when a user enters a domain name, domain name servers on theInternet are contacted to determine the IP addresses associated withthat name.

The Network includes specialized domain name servers that use advancedmechanisms to determine the IP addresses associated with a given domainname and service. These servers work seamlessly with the Internet DNSsystem. To determine the best IP address, or addresses, to return when auser requests a service on the Internet, the DNS system does thefollowing:

1. Uses IP addresses to monitor the performance of a service onindividual computers or clusters of computers

2. Determines latency and load metrics between users and servers on theInternet

3. Performs tests on the Internet to determine the quality of service auser would receive when connecting to a specific computer or cluster ofcomputers

Procedures

This section describes the procedures you can perform to implement andthen monitor the performance of the Global Traffic Management service.To implement the Global Traffic Management service, the customer or userdoes the following:

1. Sign up for the service.

2. Contact the server location and provide the following information:The domain name of the service you want the system to manage; The IPaddresses associated with that service; A description of the service andhow it should be tested for performance and availability; The intervalafter which tests should be performed; What the service check shouldlook for, such as specific information in a returned Web page. Whetherthe user would like traffic weighted so that more traffic is sent to oneIP address over another.

In addition to the normal routing around failures to the closest server,the system can also be set up for security purposes. The system cancontain hidden IP addresses that are only given out in the case offailure of other IP addresses. The user might want to use this featureto prevent a denial of service attack. If one IP address is attacked andbecomes unavailable, another will then appear and traffic will be routedto it. This can make attacking a Web server more difficult since the IPaddress is not published until the failure occurs.

In a specific embodiment, the method allows the user to monitor theoperation of the Global Traffic Management service for domain names.Preferably, the method outputs information on a Web-based,user-interface that runs on a secure server on the Internet that can beaccessed only through a Web browser that supports secure connections(SSL). Here, a start section of the user interface contains a table thatshows all the domains and associated origin domains your account is setup to use. See FIG. 6A.

In an alternative embodiment, we can also view the last 24 hours oftraffic management activity for a given domain:

-   1) Access the user interface at:-   https://speedeye.speedera.com-   2) Find the Recent Activity page in the Traffic Management section    of the interface.

The main graph in the page shows how traffic was routed over the last 24hours. A dotted vertical line separates yesterday on the left from todayon the right. The lines in the graph show how many times each IP addresswas given out. See the example in FIG. 6B.

In the example, the present Global Traffic Management system made 198120traffic routing decisions over a 24-hour period. The lower decision linein the graph represents an IP address for “Delhi, India.” The upperdecision line represents an IP address for “Santa Clara, Calif.; UnitedStates.” The Y axis represents the activity levels. The X axisrepresents the Santa Clara time: N for noon, P for p.m., and A for a.m.

At 6:00 a.m. in Santa Clara, one line dropped to the bottom of the graphand the other spiked upward. This happened because the system routedaround a failure at a data center. When the “Delhi” IP address failedits service test, the Global Traffic Management system routed traffic tothe “Santa Clara” IP address.

The example also shows that the “Delhi” IP address is more active atnight (Santa Clara time), and the “Santa Clara” IP address is moreactive in the daytime. The difference in activity results from thechanges in time zones. When people in India are active, the trafficmanager routes their requests to the closest available server with thebest service response time. For users in India, when it is theirdaylight and their peak time, the best IP address is often the site inDelhi. For users in the U.S., when it is their peak time, the best IPaddress is the site in Santa Clara.

In still an alternative embodiment, we can view the last 24 hours oftraffic management activity by location for a given domain:

-   1. Access the user interface at:-   https://speedeye.speedera.com-   2. Find the By Location page in the Content Delivery section of the    user interface.

Here, a world map and a bar chart appear. They show where the trafficmanager routed traffic (geographic and network locations) over the last24 hours for a given domain name. See the example in FIG. 6C. Thebar-chart example shows the number of times each location was chosen toserve traffic over the last 24 hours. In the example, the trafficmanager chose the “UUNET/sclara” (Santa Clara, Calif.; United States)location to serve most of the traffic.

In other aspects, the method includes performing tests. Here, theinterface also contains a utility that allows the user to check a Webpage from multiple locations. If an HTTP service is used, a quick statuscheck can be executed as follows:

-   1) Access the user interface at:-   https://speedeye.spedera.com-   2) In the text entry field, enter the URL for the page you want to    check.-   3) Select the locations from which you want to check the page.-   4) Press the Check button. This causes servers at the location, or    locations, selected to download the Web page associated with the URL    you entered in Step 2.

When the servers have completed downloading the page, thepage-performance results are shown in the form of tables and graphs. Thefirst table (see FIG. 6D) is the overall performance table. It appearsat the top of the results. In this example, the page took an average of500 milliseconds (half a second) to download from the first threelocations (rows) and 1200 milliseconds (1.2 seconds) from the lastlocation.

A server name, physical location, and network location identify eachlocation. For example, the last location in FIG. 6D is labeled as“server-4/sterling/exodus.” This label identifies a server on the Exodusnetwork located in Sterling, Va., USA.

After the overall timetable, details for each location are presented inindividual tables. FIG. 5 shows a table containing the details for thelocation “server-14, dc, cw,” a server located on the Cable & WirelessNetwork in Washington D.C., USA. The IP address of the actual server isshown in the heading of the table so you can perform additional tests,if needed, (traceroute and so on) on the actual server performing thetest. The Location table in FIG. 6E shows data for the www.speedera.comWeb site.

The graph in FIG. 6E shows the performance for downloading specificcomponents of the page. This table shows that the majority of the timespent in the download was spent downloading the home page itself.

The colors in the graph show the different components of the downloadincluding the DNS lookup time, connect time, and so on. The first timeyou check a page, the DNS times will likely be very high. This highreading results from the way DNS works in the Internet. If a domain nameis not accessed within a specific amount of time (the timeout period),the information will expire from the DNS caches. The first request willagain need to walk through the Internet's hierarchical system of DNSservers to determine which one is authoritative for a given domain name.

To get more accurate results, a page can be hit twice and the resultsfrom the second hit can be used. This will give you a more accuraterepresentation of what the performance is like when the page is beinghit on a regular basis. In the Location Table, the graph is followed bythe actual raw data that makes up the graph. Each row displays thefollowing elements:

-   URL. The URL component downloaded-   IP Address. The IP address of the server contacted to get the data-   ERR. The error code (where 0 is no error)-   HRC. The HTTP response code (where 200 is OK)-   LEN. The length of the data downloaded-   CHK. A checksum of the data-   STT. The timing in milliseconds for the start time-   DRT. DNS response time in milliseconds-   COT. Connection Time—Syn/SynAck/Ack Time-   DST. Data start time when first packet is downloaded-   FNT. Final time when download is complete-   END. The total millisecond timings for portions of the connection

In a specific embodiment, the Global Traffic Management (GTM) systemautomatically routes around failures to services on the IP addresses itmanages. Here, the system can also be: Adding or removing a domain namefrom the system; Adding or removing IP addresses from the system; andChanging the way a service is monitored.

The Speedera DNS server (SPD) is the core component of the Speedera GTMsolution and provides load balancing across the servers distributed allover the Internet. The SPD acts as the traffic cop for the entirenetwork. It handles the DNS requests from the clients, resolvinghostnames to IP addresses. The SPD makes the decisions about which IPaddress to return for a given hostname based on the static mapping ofhostnames to the servers (configuration file), information it collectsabout the state of the servers in the network (service probes),information about the network latency from the servers to the client(latency probes), the packet loss information for the POP (packet lossprobe), bandwidth usage for the POP (SERVPD) and static latencyinformation (client configuration). This enables the invention to directclients to the servers that are ideally suited to service the clientrequests.

If SPD cannot answer the request, it will forward the request to thenamed server. This allows SPD to handle only the queries that arerelevant to the GTM solution. SPD handles the following type of queries:

-   -   A Records    -   PTR Records    -   SOA Records    -   LOC Records    -   NS Records    -   ANY Record

SPD server is designed to work around problems in the network. It canhandle a single server or a single POP failure. It can also work aroundmore catastrophic failures such as all latency probes going down. Inthese extreme cases, the load balancing will not be optimal, but the SPDand the entire Speedera Network will still function.

SPD supports a two-tier architecture that can be used to increase thenumber of DNS servers in the system to more than the maximum allowed for.com domains. It can also be used to direct the client DNS servers tothe closet Speedera DNS servers.

SPD logs the statistics about the IP address it gives out in response toincoming requests. This can be used to monitor the effectiveness of theGTM solution in distributing load across multiple servers.

Referring to FIG. 7, the SPD is highly scalable; it uses hashing tablesoptimized for block memory allocation to speed up access to all theinternal tables. It can easily scale to handle thousand of servers andhostnames in the network. The only limiting factor is the amount ofphysical memory available on the servers. The figure below shows howSPDs interact with other components.

-   1. SERVPD 704, 708, sends the load information about all the servers    in the POP 707, 711, to all the SPD servers 702, 703, periodically.    This information is also used to update the bandwidth usage for the    POP 707, 711.-   2. SPKT 705, 709, sends the packet loss information to all the SPD    servers 702, 703, periodically.-   3. Client DNS 711 sends a DNS request to SPD server 702.    -   3.1. If the SPD server 702 is not responsible for the zone in        which the client address falls, it forwards the request to one        of the SPD servers 703 responsible for the zone.-   4. SPD 703 uses the cached latency, load and packet loss values to    determine the address to return. SPD 703 collects all the probe    information asynchronously to improve the response time for the DNS    requests.    -   4.1. If it was a forwarded request, SPD server 703 sends the        response back to the SPD server 702 that forwarded the original        request.-   5. SPD 702 sends the response back to the client-   6. SPD 702 sends a Latency request to LATNPD 706, 710. If the probe    method for the client 701 is specified in the client configuration    file, it sends the probe method to be used along with the latency    request. SPD 702 sends latency requests only for the servers    configured for the hostname for which it got the DNS request.    Latency requests are only sent for the servers with dynamic latency    value and if latency is factored into the load balancing algorithm.-   7. LATNPD 706, 710, probes the client 701 to determine the latency    and sends the latency information to all the DNS servers in the same    zone.    Configuration Files

The configuration file contains all the static information about theSpeedera Network. It contains the list of POPS and the servers presentat each POP. It also contains the list of hostnames serviced by theSpeedera Network and maps the hostnames to the servers that can servethe content for that hostname. Most of the parameters needed toconfigure SPD are contained in the configuration file and can be used tofine-tune the load-balancing algorithm, frequency of probes etc.

In addition to the main configuration file, there is a clientconfiguration file that can be used to specify the static latency from aclient to the various servers in the network and to specify the latencyprobe type for a give client. It can also be used to specify conditionsunder which a client is probed (Never, always, in case of a serverfailure).

Service Probes

Service Probe Daemon (SERVPD) periodically probes all the servers in thePOP and sends the status information back to all the SPD servers in theSpeedera Network. There is one service probe for each type of servicethat is supported by the GTM. This allows the fine tuning of eachservice probe to return the load metrics that accurately reflect theload on the server for that service. For example, for HTTP the timetaken to retrieve a standard Web page from the Web cache as the loadmetrics. There is also a generic load probe that measures the CPU andmemory utilization of the servers. This probe can be used as the loadmetrics for the services for which there are no custom service probes.Currently there are custom service probes for HTTP, HTTPS, FTP andstreaming servers.

The load information is used by the SPD to make the decision about whichserver to return. SPD keeps track of how old the load information is, sothat if the entire POP goes down, it can detect it by simply looking atthe load timestamp. If the load information for a server is stale, orthe server is down, the SPD tries not to direct any traffic to thatserver.

The special service type of NOLOAD has a static load value of 1 and itstime stamp is always current. This service type can be used to loadbalance services for which we do not have a probe and want to assumethat they are always up. It can also be used to effectively factor serveload out of the load-balancing algorithm.

Bandwidth Probe

There is no separate bandwidth probe. The SNMP probe in SERVPD is usedto measure the bandwidth utilization for the switch. The aggregatebandwidth usage for POP is measured as the sum of the load metrics forall the servers in the POP with the service type of “SWITCH”.

Latency Probes

Latency Probe Daemon (LATNPD) is used to determine the network latencyfrom a POP to the client. Whenever SPD gets a request from a client, itsends a latency request for that client to the latency probes. Thelatency probes then find the network latency from the POP to that clientand return it to all the SPD servers in the same zone. LATNPD uses anumber of different probes to determine the latency. Multiple probetypes are required since all the clients do no respond to a single probetype. Probe types include PING, DNS PTR, UDP packets to high portslooking for a noport responses as well as any others that may generate areply without spending much time at the target location. The order inwhich these probes are used to determine the latency can be configuredusing the configuration file. The type of probe used to determine thelatency for a given client can also be specified in the clientconfiguration file.

SPD sends latency requests only for the servers configured for thehostname for which it got the DNS request. Latency requests are onlysent for the servers with dynamic latency value and if latency isfactored into the load balancing algorithm.

Both LATNPD and SPD cache the latency information. SPD sends a latencyrequest only to a subset of the latency probes and it sends the requestonly if the latency information it has is stale. LATNPD does a probeonly if the latency information it has is stale, otherwise, it returnsthe values from its cache. This is done to reduce the amount of trafficgenerated from the latency probes to the client machines. To furtherreduce the latency probe traffic, static latency information can beinput into SPD. SPD also saves the dynamic latency tables across systemshutdowns to reduce the latency traffic at startup.

Packet Loss Probes

The Packet Loss Probe (SPKT) is used to determine the packet loss for aPOP. A limited subset of SPKT daemons probe all the POPs in the SpeederaNetwork to determine the packet loss for the POPs and report it back toSPD. Only a limited subset of POPs do the actual probing to reduce theamount of network traffic. The probe interval, number of POPs doing theprobing, packet size, and number of packets used to determine the packetloss can be fine tuned using the configuration file.

Persistence

SPD also supports persistence. For persistent hostnames, SPD returns thesame IP addresses, for a given client. The SPD server maintains a tablecontaining the IP address given out for a given hostname to a client.This table is created dynamically in response to incoming requests andis synchronized across all the SPD servers responsible for a given zone.If the same client tries to resolve the hostname against a different SPDserver in the future, it will get the same result. Also, access andrefresh timeouts for the persistent entries can be configured on a perhostname basis.

Zones

To reduce the memory requirements and network traffic, the entireInternet address space is broken up into multiple zones. Each zone isassigned to a group of SPD servers. If an SPD server gets a request froma client that is not in the zone assigned to that SPD server, itforwards the request to the SPD server assigned to that zone. The SPDservers need to keep latency and persistence information only for theclients that fall in the zone assigned to the server. The latency probesonly send the client latency information back to the SPD serversresponsible for that client. Also the SPD servers only need tosynchronize the persistence table with the SPD servers responsible forthat zone, not all the SPD servers in the network.

Each SPD server probes all the other SPD servers to determine thelatency. When SPD has to forward the DNS request to servers in the otherzone, it selects the server with the best (lowest) latency value. Thisallows the SPD server to dynamically load balance between the SPDservers in the same zone and avoid servers that may be down or arehaving some other problems.

In the DNS response SPD includes the SPD servers that are authoritativefor a given client address. That way the client can query theauthoritative name servers directly next time, avoiding the delayinvolved in forwarding the DNS request from one SPD server to another.

Two Tier Architecture

SPD supports a two-tier architecture that can be used to increase thenumber of DNS servers in the system to more than the maximum allowed for.com domains. It can also be used to direct the client DNS servers tothe closet Speedera DNS servers and to prevent the client DNS serverfrom flip-flopping between all the DNS servers authoritative forspeedera.net domain.

When returning the NS records, the normal load balancing is performed todetermine the SPD servers that are best suited to handle the queries forthe client and return only those NS records. This helps in directing theclient DNS server towards the SPD servers that is best suited to handlethe queries for it.

To support the two-tier architecture the hostname entries aredynamically mapped in the configuration file to the second tier domainnames (www.speedera.net to www.edge.speedera.net). SPD provides supportfor any number of second level domains. The “edge” and “persistent”domains are special domains that are used for the dynamic transformationof the host names.

The persistent.speedera.net domain is used to handle all the persistenthostname queries. If the “persistent” domain is not defined then theroot domain (speedera.net) is used to handle the persistent queries.

The following algorithm is used to generate the mapped hostnames andvalidate the hostnames in the configuration file:

-   -   1. Get the domain authoritative for the hostname, using longest        suffix match. Root is authoritative for all the hostnames that        do not have the speedera.net suffix.    -   2. If the hostname is of the type GTM and persistent        -   a. If persistent domain is defined and the authoritative            domain for the hostname is not persistent.speedera.net then            flag an error        -   b. If persistent domain is not defined and the authoritative            domain for the hostname is not root then flag an error    -   3. If the hostname is of the type GTM do not do the mapping    -   4. If the hostname is persistent and a domain other than the        root is authoritative for that hostname and if persistent domain        is defined and the authoritative domain for the hostname is not        persistent.speedera.net then flag an error    -   5. If the hostname is persistent and a domain other than the        root is authoritative for that hostname and if persistent domain        is not defined flag an error    -   6. If a domain other than the root is authoritative for the        hostname do not do the mapping    -   7. If the hostname is persistent and “persistent” domain is not        defined, do not do the mapping.    -   8. If the hostname is not persistent and “edge” domain is not        defined, do not do the mapping.    -   9. If the hostname is static do not do the mapping.    -   10. If the hostname is persistent, MapDomain is        persistent.speedera.net.    -   11. If the hostname is not persistent MapDomain is        edge.speedera.net.    -   12. If the hostname belongs to one group of servers and uses        global load balancing parameters, map the hostname to        <service>-<group>.<MapDomain>    -   13. Remove the domain suffix from the hostname    -   14. Map the hostname to <prefix>.MapDomain>

The Speedera Network consists of a number of Linux machines runningSpeedera software. Speedera software consists of eight components thatare delivered as a single product. When deployed across a large numberof machines, it creates a network that provides a complete solution forcontent hosting and delivery.

Customers can store content such as HTML, images, video, sound andsoftware in the network for fast and highly available access by clients.The network also provides load balancing and high availability forservers outside the network. Customers with generated content, such assearch engines, auctions and shopping carts, can use the latter featureto add their own content servers to the network.

The system requires no software or hardware to be installed or run at acustomer site. The system may be monitored using a standard Web browser.It provides an HTML interface that displays the networks current statusas well as historical statistics.

Software Components

The system is comprised of the following distinct software components:

-   -   NameServer    -   WebCache    -   Streaming Media Servers    -   FileSync    -   NetProbes    -   LogServer    -   NetView    -   AdminTools    -   Shared

NameServer

DNS server software that performs name to IP address mapping. Whenqueried to resolve a name from a client's DNS server, it returns an IPaddress that has the ability to serve content for that name and that isbest suited to handle the request in terms of load (service health),latency, packet loss and availability. The DNS server writes loginformation to files that are picked up and maintained by the LogServersoftware.

WebCache

Caching Web server software that responds to requests for Web contentfrom clients (Web browsers). If the requested content does not exist inmemory, it will generate a request to an origin site Web server to fetchthe content. The caching servers write information about the contentdelivered to log files that are picked up and maintained by theLogServer software.

Streaming Media Servers

The streaming media in the servers will be off the shelf streaming mediaservers including ones from Real Networks, Microsoft and Apple. Alogging system allows the logs to be picked up by the LogServer softwareand plugins allow the configuration of the servers remotely.

FileSync

The FileSync software is the infrastructure to support publishing filesand synchronizing them from one location to many locations. These areused to publish large download files and also to publish on-demandstreaming media files to the streaming media servers.

NetProbes

A number of probes that include probes that:

-   -   Determine server load and availability (including service        health, load and availability)    -   Determine packet loss and latency problems on links in the        network    -   Perform content checks to ensure servers are delivering correct        content    -   Determine latency between points on the network and clients of        the network    -   Perform ongoing monitoring of services

Probes run constantly and send results to servers running NameServersoftware. The also log results to a log file that is picked up andmaintained by the LogServer software.

LogServer

Server software that picks up log files and then transmits them,receives them in a central location, stores them on disk, breaks themout into categories and processes them to generate statistics andmonitoring information. The software also responds to requests forcurrent and historical information from servers running NetViewsoftware.

NetView

Server software that provides an HTML interface to current andhistorical statistics for end-customers and network operations.Information about the network is obtained from servers running LogServersoftware. Web server CGI programs are used to provide the HTMLuser-interface. NetView software also provides an interface that allowscustomers to flush content from the network as they update the contenton their servers, manage files in the network, and set up live streamingevents.

AdminTools

Tools to configure and administer the site including tools to spider aWeb site to load the caches with content and tools to update the globalconfiguration file.

Shared

A set of client and server programs that all the various softwarecomponents require. This includes a server that transmits and receivesconfiguration files. Installing this software is not an option. It isinstalled automatically when any one of the other software components isinstalled.

Any combination of the software components (with the exception of“Shared” which is always installed) can be installed on a singlemachine. In a normal deployment, however, many machines will serve asingle purpose (DNS name server, for instance) and will only have one ofthe software components installed.

How the System Operates

The Speedera Network consists of a number of server machines installedat various points of presence (POPs) around the world. Each POP willcontain some mix of the Speedera software.

The vast majority of POPs will contain NetProbes and WebCache software.The NetProbes software performs network latency probes from each POP todetermine the latency from users to the POP. The NetProbes software willalso run probes against other POPs and perform content verification toensure machines at the various POPs are operating correct. The WebCachesoftware is used to deliver content.

A number of the POPs will need to be outfitted with large disk storageand will contain Streaming Media servers and FileSync software. Alimited number of POPs will contain NameServer software to performtraffic management for the whole system.

The Speedera Network Operations Center (NOC) contains NetView,AdminTools and LogServer software. Two NOCs can be created forredundancy and in the case of the failure of one, the backup NOC shouldpick up automatically.

With respect to FIG. 8, a four POP Speedera Network is shown. The dashedlines and triangles in the diagram show the path network traffic followswhen a piece of stored content is initially published to the network.Three content delivery POPs 802, 803, 806, and one NOC 805 are shown.Two POPs are hosted at Globix, one in Europe 802 and one on the eastcoast of the USA 803. One POP is deployed at Exodus on the west coast ofthe USA 806.

As stated above, the POP servers contain a mix of Speedera software. POP802 contains NetProbes 807, WebCache 808, 809, and WebServer 810. POP803 contains NetProbes 811, WebCache 812, 813, WebServer 814, andNameServer 815. The NOC 805 contains NetView 819, AdminTools 818,LogServer 817, 816.

Customers of the Speedera Network will maintain their own Web server (orservers) with their copy of their content on it. They don't have tochange the way they test and manage their Web site in any way to use thecontent hosting service.

The Speedera network provides two primary services. First, it providescontent hosting for content that can be cached and stored (images,video, software, etc.). Second, it provides load balancing and trafficmanagement for services that can't be stored. The latter is used to loadbalance search engines, shopping engines, etc. The network also containsother services including monitoring and live streaming, however, themost basic services are content hosting and load balancing.

Content Hosting

To host HTTP or HTTPS Web content on the Speedera network, customerseither delegate a DNS name to Speedera or host content under aspeedera.net domain name.

In the former case, the customer might delegate “images.customer.com” toSpeedera's DNS servers using a CNAME or by directly delegating thedomain. If the customer already uses an images.customers.com domain(some customers use this method for static content, for example EBayuses pics.ebay.com) they wouldn't need to make any changes to their Website to have their content published to the network. The Speederanetwork gets all hits to images.customer.com and any time the Speederanetwork gets a hit for content it did not contain, it goes back to thecustomer's Web site to retrieve the content and store it in the system.Once stored in the system, the customers Web site is never hit for thatpiece of content again.

When a customer updates its Web site, it can tell the Speedera networkthat the content was updated by entering its URL on a Web page used bySpeedera customers to invalidate content. If multiple changes to theirWeb site are made, they can invalidate whole trees of content or simplythe whole Web site. In the latter case, their Web site would be flushedfrom the system and the next hit would cause the content to be grabbedfrom their Web site.

Alternatively, the Web cache could make if-modified-since requests backto the origin site at specified intervals to check to see if the contentit has cached is fresh. Also, the cache can look at expiry headers inthe HTTP content it retrieves from the origin site to ensure freshness.

If the customer uses the speedera.net domain name to host their content,they don't need to delegate a domain name to Speedera. Speedera willcreate a “customer.speedera.net” domain name and associate it with someportion of the customer's Web site. If customer.speedera.net gets a hitfor content it does not contain, it will hit the appropriate content onthe customer's Web site to pick up that content and store it in thenetwork.

In both cases, the path network traffic flows is similar. Consider thecase where the customer has delegated images.customer.com to Speedera tohost their images. The path of the first user request is as follows:

-   1. User hits www.customer.com generating a DNS request to their    client DNS-   2. Request to resolve www.customer.com from client DNS goes to    customer.com DNS server-   3. customer.com DNS resolves the name to the customer's Web server    IP address-   4. Web page is returned to user-   5. Web page has embedded tags to get images from    images.customers.com-   6. Request to resolve images.customers.com goes to a Speedera DNS    server-   7. NameServer software on the DNS server returns the Speedera    WebCache IP address that is closest to the user, available and least    loaded-   8. WebCache does not have the content for the request so it performs    HTTP request to the customer's Web site to obtain the content

The next time the request for the same content comes through the system,it will come directly from the cache.

If a customer hosts content off the speedera.net domain name(customer.speedera.net), the process is exactly the same as the processwhen the content is hosted on a name delegated by the customer.

Traffic Management

Another service the Speedera network provides is load balancing andtraffic management for servers that aren't in the network. By combiningtraffic management and content hosting, the network can provide acomplete load balancing and high availability solution for Web sites.

The network provides load balancing at the DNS level. As in contenthosting, the customer will either delegate a DNS name to Speedera or beassigned a speedera.net domain name. When the Speedera DNS serverreceives a request to map a name to IP address it will return an IPaddress that is best suited to handle the response. The IP addressreturned will be the server that is closest to the user (latency), hasthe least load and that is available and can handle hits to that domainname.

The DNS level load balancing will commonly be used in combination withcontent hosting. When both are used in combination, the path a userrequest follows is:

-   1. User hits www.customer.com generating a DNS request to Speedera    DNS-   2. Speedera DNS determines which customer Web server is best suited    to handle request-   3. Customer's Web server generates main page and returns to user-   4. Web page has embedded tags to get images from    images.customers.com-   5. Request to resolve images.customers.com goes to a Speedera DNS    server-   6. NameServer software on the DNS server returns the Speedera    WebCache IP address that is closest to the user, available and least    loaded-   7. If WebCache has content cached the content is returned, otherwise    process is as above/

Notice that high availability and high performance are available fromthe beginning. All DNS requests go through the Speedera network. Contentthat can be hosted is hosted through the Speedera network so it may bedelivered from a point closest to the user.

To determine latency from the client DNS to the customer's server IPaddresses, latency information is used from the closest POP to thecustomer location. In some cases, the customer may be hosting at aco-location facility we already have latency probes running on. Forlarge customers that have servers located at a location that is notclose to one of our POPs, we could run a latency probe server at theirsite.

When used for traffic management, the customer must have a setup thatallows for failover. If the customer only has one IP address for theirwww site, then the Speedera network can't provide any load balancing orhigh availability for it. When the customer has 2 or more IP addresses,the network can provide load balancing, high availability and closestpoint matching for their service.

Configuration

The configuration of the Speedera Network is maintained by centrallymanaged configuration files. These files are known as the “globalconfiguration” files or “Speedera configuration” files. Every server inthe network that needs configuration information has a copy of theappropriate current Speedera configuration file.

A configuration file contains all the configuration information for thatportion of the network. Some of the data the configuration file containsis:

-   -   List of servers allowed to change the configuration    -   List of domains the network is responsible for    -   List of services the machines in each POP supports    -   List of probes that perform latency checks at each POP

At any time, a new configuration file can be pushed to all machines thatneed it in a safe manner using the AdminTools software.

No statistics, status or extended information is kept in theconfiguration file. It must contain only the configuration informationand not customer names or any other information not required by thenetwork to keep its size at a minimum and to reduce the frequency of itneeding updates.

Monitoring

Real-time and historical information about the site is available throughHTML by connecting to a server running NetView software.

Maintenance

The system is maintained using the AdminTools software. Some limitedmaintenance is available through HTML including the ability to purgecontent from all the caches in the network when original content isupdated.

Software Requirements

Referring to FIG. 9, the Speedera software consists of several distinctsoftware components. The various components, NarneServer server 901,NetProbes 907, LogServer server 903, NetView server 902, WebCache server906, and WebServer server 905, interact with each other and the customerWeb site 904, as described above.

WebCache Description

Terminology

-   CacheServer (aka WebCache)-   A POP server that serves requests that are cached in memory and on    disk.

WebCache is the Web caching server software that responds to requestsfor Web content from clients (Web browsers). If the requested contentdoes not exist in memory or on disk, it generates a request to an originsite to obtain the content. The caching servers write information aboutthe content delivered to log files that are picked up and maintained bythe LogServer software.

At a regular fixed interval, the server compresses and sends the logs ofthe content delivered to the log analysis servers. This information isused for billing as well as by customers for log analysis. In the casewhere a hardware box is used, the server that sends the logs will needto be written as a separate daemon, but it will exist as part of theWebCache software.

Netprobes Description

The NetProbes software component comprises server software executing ona computer system that performs probes to:

-   -   Determine server load and availability    -   Perform content checks to ensure servers are delivering correct        content    -   Determine packet loss and latency on individual routes    -   Determine latency between points on the network and clients of        the network    -   Perform ongoing monitoring of services

Probes run constantly and send results to servers running NameServersoftware. They also log results to a log file that is picked up andmaintained by the LogServer software.

The NetProbes software performs service availability/metric and latencyprobes and sends the results to servers running NameServer software.There are 2 fundamental probes: (1) service probes; and (2) latencyprobes.

Service probes determine service availability and load (metrics) foreach content delivery machine in the network. Service probes monitorthings like HTTP total response time, FTP total response time, etc.Service probes run constantly, sending current metric and availabilityinformation to all DNS servers in the network. Probe intervals andconfiguration of service probes are set in the global configurationfile.

Latency probes determine latency from their point to client DNS serversthat send requests to Speedera DNS servers. The Speedera DNS serversdrive the latency probes. When a DNS server determines that it needslatency information from a probe, it sends a request to the probe andthe latency probe will probe the client DNS server and respond with theresult.

The probe servers do not store the results of the probes, they simplysend them to other servers over the network. Each piece of probeinformation has a timestamp of when the probe occurred so the receivingserver can determine how stale the probe information is.

Overview

The NetProbes servers are responsible for providing the network withservice and latency metrics. The NetProbes servers continuously performprobes and send metrics to DnsServers and LogServers.

With respect to FIG. 10, there are two different types of NetProbes, aServiceProbe 1003 and a LatencyProbe 1001. In the Speedera configurationfile, each POP is assigned an IP address for a ServiceProbe 1003 andLatencyProbe 1001. They may be different but in most cases, a singlemachine will perform both service and latency probes.

ServiceProbes

A ServiceProbe 1003 figures out service metric information for serversin the Speedera Network. Each server in the Speedera Network supportsone or more services. For example, a Web server machine provides an HTTPservice. An FTP server provides an FTP service.

The value of a service metric is dependent on the metric type. Forexample, an HTTP metric may have a value that represents the machine'sresponse time to an HTTP request in milliseconds.

The CPU/memory load of a machine is available using the LOADP service ifthe machine is running a LOADP daemon. LOADP is a Speedera protocoldescribed later in this document that returns a value describing acombination of CPU load and swap memory utilization.

In the Speedera configuration file, each DNS name has a set of servicesassociated with it. The ftp.speedera.com DNS name may serve FTP contentand therefore have an FTP service associated with it. A www.speedera.comdomain name would have the HTTP service associated with it. Aspeedera.com domain name may have FTP and HTTP services associated withit.

Service metrics are used by DnsServers 1008 to determine the best serverto return for a given DNS name. A DnsServer 1008 getting a request forftp.speedera.com, for example, would know the request is for the FTPservice and could compare the FTP service metrics of two servers todetermine which is the best to return.

A DnsServer 1008 getting a request for speedera.com may not know whichservice will be utilized, so it may simply use the LOADP metric todetermine which machine has the least loaded CPU and available memory.

LatencyProbes

A LatencyProbe 1001 figures out the latency from its location to otherlocations on the Internet. DnsServers 1008 need to know the latency fromvarious latency points to determine which point is closest to a user.

When a user hits a Web site, such as www.speedera.com, his machine makesa request to its local DnsClient. This DnsClient, in turn, ends upmaking a request to a Speedera DnsServer 1008 if the server isauthoritative for the www.speedera.com name.

When the Speedera DnsServer 1008 gets a request from a DnsClient, itneeds to determine which servers are closest to the client as well aswhich servers have the best metrics to handle the request.

To determine which servers are closest to the client, the DnsServer 1008will consult tables that contain latency information from variousLatencyProbes. Each server in the Speedera Network is contained in a POPand each POP has a LatencyProbe 1001 assigned to it.

It's the job of the LatencyProbes to perform latency tests toDnsClients. A LatencyProbe 1001 builds up a table of DnsClients to testover time, receiving the list of which DnsClient IP addresses to probefrom the DnsServers in the network.

ServiceProbes

ServiceProbes determine service metric information for servers in theSpeedera Network. The following types of service probes are available:

-   -   HTTP    -   HTTPS    -   FTP    -   Streaming Media (Real, Microsoft, etc.)    -   Generic SNMP        Configuration

A ServiceProbe determines which metrics to calculate and what servers toprobe by reading the Speedera configuration file. The configuration filecontains a LatencyProbe and ServiceProbe entry for each POP.

When the ServiceProbe is configured, it will scan the entire list ofPOPs in its configuration and examine each ServiceProbe entry todetermine if it is the ServiceProbe for that POP. If it is, it will readthe list of servers and services contained in the POP and add them tothe list of servers to monitor.

Tests

Each service supported by the Speedera Network has a metric testassociated with it. HTTP, for example, will have a metric associatedwith it that is the total time it takes to process a HTTP request. Theservice test for HTTPS is identical to the service type for HTTP. Theonly difference being that a secure session is established for the GETrequest. Secure sessions are not shared; rather a separate securesession with full key exchange is done for each test. For FTP, the testconsists of establishing a connection to the FTP port on the server, andmaking sure that a ready response (220) is obtained from the FTPservice. The connection is then closed. Different types of searchengines will have different types of tests.

At first glance, it may seem that we could simply use the LOADP metricas the HTTP or FTP metric. However, the LOADP metric doesn't accuratelyreflect how long a given HTTP request might take to execute on a server.It's best to produce a metric that is based on user-experience ratherthan trying to infer a metric from other means.

The ServiceProbe performs metric tests at various intervals and adds aline for each test to an internal table. The internal table looks like:

TABLE 1 Server Metric Table Example ServerIP ServiceID ErrorCode MetricTimeStamp 1.2.3.4 [1] HTTP [0] NONE 80 103019419 1.2.3.4 [0] LOADP [0]NONE 340 103019421 1.2.3.4 [2] FTP [5] BAD_REQUEST 65535 1030194222.3.4.5 [1] HTTP [0] NONE 70 103019424 2.3.4.5 [0] LOADP [0] NONE 330103019425

The ServiceID field in the table is the id that identifies the servicethe metric is for. Each service in the Speedera network has an idspecified in the services section of the Speedera configuration file.The ErrorCode field is an internal service-specific error code that canbe used to help trace failures. An ErrorCode of 0 is used to signify noerror. A metric value of 65535 also generally denotes a verification ortimeout failure. The TimeStamp is the time the metric test wasperformed.

A test can fail either from a verification failure or a timeout. Anexample of a verification failure might be an HTTP test failing becausea response does not contain an expected piece of text. Each test canalso time out if there is no response for some period of time. Thetimeout, in milliseconds, for each test is set in the Speederaconfiguration file.

SERVP Protocol

At various intervals, the ServiceProbe sends an update to all DnsServersin the Speedera Network using the Speedera SERVP protocol and writes theupdate to a log file. The update consists of the values of all testssince the last update. The Speedera configuration file contains twovalues that determine the interval for server metric updates “sendinterval” and “send size”.

The send size is the maximum size of an individual server metric updatein bytes. As the probe runs, it accumulates metrics and keeps track ofthe size of the update packet related to the metrics. If the updatepacket reaches the size of the send size, the probe sends an update. Ifthe send size is not reached, then the packet is sent when the sendinterval expires. This causes the update to be sent when it gets toolarge, by reaching the send size, or when the send interval expires.

Each update is formatted according to the SERVP protocol. All integervalues passed in the protocol are passed in network byte order.

The protocol is defined as:

TABLE 2 SERVP Server Metric Update Protocol Name Type Description magicuint32 magic number numRows uint16 number of rows of data IPAddr uint32row[0] IP address serviceID uint16 row[0] service ID errorCode uint16row[0] error code metric uint16 row[0] metric timeStamp uint32 row[0]time stamp . . . . . . . . . timeStamp uint32 row[n] time stampLOADP Protocol

To determine the load on a machine, the invention provides a LOADPserver. The serviceProbe sends a request and a LOADP server respondswith a packet containing the various metrics of the server, e.g. Cpu,memory, snmp, network and scsi metrics. The service probe combines theserver metrics to arrive at a load metric which is then sent to theserver.

The communication between the client and server is accomplished usingthe LOADP protocol. All integer values passed in the protocol are passedin network byte order.

A request to a LOADP server follows the following protocol:

TABLE 3 LOADP Request Name Type Description magic uint32 magic number

A response from a LOADP server follows the following protocol:

TABLE 4 LOADP Response Name Type Description magic uint32 magic numberError uint32 Error code - bit mask; various bits are set to indicatedifferent errors: #define LOADP_OK 0x0 #define LOADP_ERR_LOAD 0x1#define LOADP_ERR_MEMINFO 0x2 #define LOADP_ERR_NETINFO 0x4 #defineLOADP_ERR_SNMPINFO 0x8 #define LOADP_ERR_SCSIINFO 0x10 Time Uint32Timestamp when load was measured. The LOADP server refreshes its metricsat the most once every 10 seconds. CPU/MEM Info LoadAverage uint32 Avgload in the last minute MemTotal uint32 Memory avl on machine (bytes)memUsed uint32 Mem used on machine (bytes) swapTotal uint32 Total swapspace (bytes) swapUsed uint32 Used swap space (bytes) Network InfoinBytes uint32 Incoming bytes inPkts uint32 Incoming packets inNetErrsuint32 Network errors on incoming packets inDrop uint32 inFifo uint32Erroneous imcoming packets - dropped, Fifo overflow, fram errorsinFrames uint32 outBytes uint32 Outgoing bytes outPkts uint32 Outgoingpackets outNetErrs uint32 OutDrop uint32 Errors in outgoing packets-Network errors, dropped packets, Fifo errors outFifo uint32 colls uint32Collisions carrier uint32 Carrier loss SnmpInfo inRecv uint32 Incomingpacket statistics inHdrErr uint32 inAddrErr uint32 inUnknownProto uint32inDiscards uint32 inDelivers uint32 outReqs uint32 Ougoing packetstatistics OutDiscards uint32 outNoRoutes uint32 reasmTimeout uint32Reassembly statistics ReasmReqd uint32 ReasmOKs uint32 reasmFails uint32fragOKs uint32 Fragmentation statistics fragFails uint32 fragCreatesuint32 TCPInfo maxConn uint32 TCP stats - some of these stats are notcorrectly maintained by the current version of Linux maxConn is alwaysreported as 0. activeOpens uint32 passiveOpens uint32 PassiveOpens isalways 0. failedAttempts uint32 estabRsts uint32 currEstab uint32 inSegsuint32 outSegs uint32 retransSegs uint32 inTcpErrs uint32 outRsts uint32UDP Info InDGram uint32 UDP statistics inNoPort uint32 inUdpErrs uint32outDGram uint32 SCSI Info numTxn uint32 SCSI stats numKBytes uint32LoadP Metrics numReq uint32 Number of requests received by LoadPnumRefresh uint32 Number of times LoadP refreshed its metrics on themachine errReq uint32 Number of err requests errRespSend uint32 Numberof errors in sending responses ErrLoad uint32 errMemInfo uint32errNetInfo uint32 Error count for various types of load metrics: load,meminfo, net info, snmp info, scsi info errSnmpInfo uint32 errScsiInfouint32 numSigHups uint32 Number of SIGHUPS received since last started

The load value returned by the service probe to Speedera DNS currentlyis:load=(10*loadAverage)+(swapSpaceUsed/1000000)

A machine's loadAverage is typically in the range of 1.0-10.0. TheswapSpaceUsed is in bytes and the division by 1M turns the right handside into megabtes of swap space currently used. If the server can'tcalculate the load value for some reason, it will return a load of 1000.

Logging

When a SERVP server sends an update, the update is also written to a logfile. The format of the log output is the same as the update, except:

-   -   there is no magic or numRows (no header)    -   the log file is in text file format    -   there is a delimiter between columns (pipe symbol or similar)

Referring again to FIG. 10, the Speedera LogServer daemons 1004 performthe job of sending the log file to a central location for processing.

LOADP servers perform no logging of requests or responses.

Latency Probes

LatencyProbes figure out the latency from the POP location to theclient's location (normally local DNS server). Each POP in the SpeederaNetwork has a LatencyProbe associated with it. Any number of POPs canshare the same LatencyProbe.

In the normal case, when a DnsServer gets a request from a DnsClient, itrefers to the metric tables it has built up from each LatencyProbe,finds the DnsGroup entry for the DnsClient, and compares latency valuesto find the best IP address to return. If it can't find an entry in thetables for the DnsClient, it just returns a “best guess” IP address andsends the IP address of the new DnsClient to all NetProbes in thenetwork at the next update interval.

At a regular interval, the DnsServers in the Speedera Network will senda list of the DnsGroups and DnsClient IP addresses that have recentlymade requests back to the NetProbe servers. This is used by theLatencyProbe to update the list with new DnsGroups and to update the usecounter information for existing DnsGroups.

Configuration

A machine determines if it is a LatencyProbe by looking at theLatencyProbe value for each POP in the Speedera configuration file. Ifit finds its IP address as a value for a LatencyProbe, it becomes anactive LatencyProbe.

The Latency Probe also parses the DNS Zone configuration in the Speedera

Configuration file, to determine all the DNS servers to latency metricsneeded to be sent.

Tests

Each LatencyProbe maintains a table of latency metrics from its locationto a list of DnsGroups. A LatencyProbe will scan its table at a regularinterval, looking for entries that are stale and perform probes toupdate the stale values.

The LatencyProbe maintains an internal table, with one row per DnsGroup. The columns in the table are as follows:

-   -   DnsGroup—a group of DnsClient servers (DnsClient IP addresses        masked to 255.255.255.0)    -   DnsClient[1, 2, 3] —IP addresses for 3 (or less) DnsClient        servers in the group    -   ProbeType Reverse name lookup/traceroute    -   clientIndex Index into dnsclient[ ], active client    -   ProbeStatus Status of the probe    -   TraceRouteInfo All the traceroute realted data    -   ProbeTimeStamp: time stamp of when the probe is issued    -   LatencyValue—the latency from this location to the DnsGroup    -   LatencyValueTimeStamp—the LatencyValue time stamp    -   prevLru: prey pointer in LRU list of client DNS records    -   nextLru: next pointer in LRU list of client DNS records    -   nextInHash: pointer to the next element in the same bucket

LatencyProbes perform latency tests by calculating the round trip timefor sending a packet to a DnsClient in a given DnsGroup. A latency valuefrom any DnsClient in the group will be considered to be the latency forthe whole group.

The probe has a number of tests it can perform to try and determine theround trip time. These include:

-   -   PING    -   UDP Reverse Name lookup (request for the DNS name of the        DnsClient IP address)    -   UDP Packets to high ports numbers

LATNPD can be configured to try the different probe types in any order.

Reverse name lookup is a standard DNS query that specifies a client IPaddress and asks for the client name. When the client responds thatgives the round trip time that is used as a latency value. If thereverse name lookup succeeds that latency value is FULL latencymeasurement. But if the lookup fails LATNPD tries Traceroute.

The UDP packets to high ports is much like traceroute which sends a rawUDP packet with large TTL value (64) to an unreachable port (33434) onthe client DNS. This generates an ICMP unreachable port error message tothe latency daemon. This response is used as a measure of latency. Whenthe unreachable port error arrives, it suggests that the client isreached, this is considered to be FULL latency measurement.

However, sometimes the trace route message gets lost and no responsecomes back—so the probe times out. The probe (UDP) is repeated with aTTL value of, four, for example, addressed to the client Dns with thehope that we can reach at least four hops from the source. If thissucceeds (LATNP gets a ICMP error message with code TIMEXCEED), repeatthis probe process with a TTL value incremented by four, for example,(TTL now is eight) and keep doing this until we get no response. Thiswill indicate the last reachable router and that is used as a proxy forthe real client to measure the latency value. This is treated as PARTIALlatency data.

Once FULL latency data is achieved using a client, the probe is sentonly to that client even if Speedera DNS sends new clients for the samegroup.

As mentioned above, LATNPD stores up, to three IP addresses for eachclient DNS group. So if a new client is added to a group that has onlyPARTIAL latency data available, it designates the new client as theactive client and starts the probe process all over, starting withreverse name lookup. This is done so that the new client might give theFULL latency data.

When a new client is added to a client DNS group, LATNPD tries to find afree dnsClient entry for the new client address. If it does not find afree entry it tries to replace a client that got only PARTIAL latencydata and is not actively probed.

At an interval controlled by the configuration file, the LatencyProbesends an update to all DnsServers in the Speedera Network with newDnsGroup latency information. Each DnsServer maintains a latency tableassociated with each LatencyProbe.

LATNP Protocol

The LatencyProbe uses the Speedera LATNP protocol to receive requestsfor latency metrics from the DNS servers and to update the DNS serverswith the latency information for DNS groups.

The LATNP protocol implementation is supported using two messages. Bothmessages share a common header. The header is followed by a variablenumber of request elements for the Latency Request and by a variablenumber of latency metric elements for the Latency Metric Message.

The Latency Request Message consists of the header followed by asequence of IP addresses, representing DNS groups for which metric isdesired. The format is as defined below:

TABLE 5 LATNP Latency Request Message Name Type Description Cookieuint32 magic number Version uint32 Version Status uint32 Status (ignoredfor requests). NumElem uint32 Number of request elements in the requestmessage Ip address uint32 Row[0] IP address belonging to the DNS groupfor which metric is needed IP address uint32 row[n] IP address

The Latency Metric Message consists of the common header followed by avariable number of metric elements. Each metric element consists of thedns group, latency value, and the timestamp at which latency wasmeasured:

TABLE 6 LATNP Latency Metric Message Name Type Description Cookie uint32magic number Version uint32 Version Status uint32 Status for responsemessages. Following status codes may be returned: LATNP_STATUS_OKLATNP_STATUS_VERSION_MISMATCH LATNP_STATUS_UNSPEC_ERROR (unspecifiederror) NumElem uint32 Number of latency metric elements in the messageDnsGroup uint32 DnsGroup[0] LatencyValue uint32 Latency Value for theDns group[0] Latency TimeStamp uint32 Timestamp at which latency for theDns group was measured[0] DnsGroup uint32 DnsGroup[n] LatencyValueuint32 Latency Value for the Dns group[n] Latency TimeStamp uint32Timestamp at which latency for the Dns group was measured[n]

In both cases, from the DnsClient to the LatencyProbe and from theLatency Probe to the DnsClient, updates are sent at an interval definedin the Speedera configuration file. Each Latency Metric message containsany new latency measurements made during the interval between theprevious message and the present message.

Logging

The Latency Probe logs the Statistics data periodically based on thelogInterval set in the Speedera config file.

The statistics are aggregated for all the Speedera DNS servers. Thelayout of the log file is as described here:

TABLE 7 Log file layout Name Type Description TimeStamp uint32 Timestampwhen the log file is wriiten Interval uint32 LogInterval, time intervalbtw 2 consequtive logs. Reqs uint32 Total # of request packets from allthe Speedera DNS servers. Resps uint32 Total # of response packets toall the Speedera DNS servers. InvalidReqs uint32 Total # of inavlidrequests from all the DNS servers respErrors uint32 Total # of errors insending responses (communication errors) reqMetrics uint32 Toatl # ofmetrics in all the requests from Speedera DNS servers. RespMetricsuint32 Total # of responses sent in all the responses to Speedera DNSservers. RevNameReqs uint32 Total no. of reverse name probes doneRecNameFails uint32 Total no of reverse name probes that failed.TraceRoutes uint32 Total no. of traceroute probes issued TraceRouteFailsuint32 Total no. of traceroute probes that failed (no response at all)TraceRouteFulls uint32 Total no. of traceroute probes that reached theclient Dns TraceRoutePartials uint32 Total no. of traceroute probes thatresulted in partial latency values. ProbeSendErrors uint32 Total no. oferrors in sending probes. Hits uint32 Total no. of hits for client IPaddress MissesNew uint32 Total no. of misses when a new client IP addessis looked up in the client Dns Hash table of Latnpd. This results inallocating a new client dns record and starting a probe. MissesStaleuint32 Total no. of times a client IP address is found in the client DnsHash table but invalid because since it is stale. This results insending a new probe and waiting for the response. NonStaleReplicateduint32 Total no. of client Dns Records that are not stale but replacedto accommodate new clients.LogServer DescriptionTerminologyPOP Server

Any server in a POP that runs a log distributor daemon that sends logfiles to the log collector daemons on the log servers.

Log Server/Database Server

A server machine that collects log files from the POP servers via thelog collector daemons. These log files are then processed and sent to adatabase server. The database server stores log files generated by logservers as tables. The Netview servers contact the database server toextract statistics like cache hits, billing etc.

Netview Server

A server that runs the user-interface to the Speedera Network via a Webserver. The CGI scripts on this server generate requests to the databaseserver on behalf of the clients that are connected to it.

-   -   For each unique customer hostname, the server must create a        separate log file.    -   Log files will be rotated on a regular basis (after a certain        timeout interval or a certain size threshold). Completed log        files will be placed in a well known directory. They will be        shipped automatically by the Log Server daemons.    -   Log files will contain the following fields for each serviced        request. These fields will be delimited by a separator such as |        or ^. This allows easy insertion in to a database on the        receiving end.        -   Date        -   Time        -   Full URL        -   Request Status (miss, hit . . . )        -   Request type (?)        -   Number of bytes    -   Log files will be named according to the naming convention in        the Log Server Specification. The name of the file identifies        the customer name, the machine name, the machine number, the        location, network etc.        Overview

With respect to FIG. 11, the logging subsystem consists of the followingdaemons that will be used to distribute log files from the POP serversand collect them on the Log servers. In addition to the daemons, therewill be tools to dump log data into a database. The database will thenbe queried by tools on the Netview servers for statistics and billinginformation etc.

Log Distributor Daemon

The log distributor daemon (sldd) 1113, 1114, sends log files on a POPserver 1111, 1112, to a log collector daemon (slcd) 1107, 1109, runningon a Log Server 1105, 1106. Each log distributor daemon 1113, 1114,looks in a well known location for files it needs to send. The sldd's1113, 1114, are multi-threaded and can send multiple log filessimultaneously.

Log Collector Daemon

The log collector daemon (slcd) 1107, 1109, collects log files from thelog distributor daemons (sldd) 1113, 1114, and places them indirectories specified by the date on which the files were received. Thisdaemon is also multi-threaded to handle simultaneous connections frommultiple log distributor daemons.

Database Insertor daemon

The database insertor daemon (sldb) 1108, 1110, collects the log filesfrom the directories where the collector daemon (slcd) 1107, 1109, hasplaced them. It then opens a connection to the database and puts thecontents of the log files into tables. The database insertor ismulti-threaded and can load multiple log files simultaneously into thedatabase.

Log Distributor Daemon—sldd

A log distributor daemon 1113, 1114, running on a POP server 1111, 1112does the following:

-   -   1. Check a well known directory (that is configurable) for files        that need to be sent to the log collector daemons. The file name        fully qualifies the type of file it is (one of either NetProbe,        DNS or WebCache).    -   2. Create a new thread for each file that is ready.    -   3. Each thread determines the Log Server ip to send the file to        by querying the DNS server. A query is made to log.speedera.com        If multiple ip's are returned, any random ip will be selected.        In case, the connection to that ip fails, then all other ips        will be tried in sequence till a connection is established or        all ip's have been tried.    -   4. Compress the log file and send it over.    -   5. Exit the thread.        Log Collector Daemon—slcd

The log collector daemon 1107, 1109, running on the Log Server 1105,1106, does the following:

-   -   1. Listen for connections from the log distributor daemons        (sldd) 1113, 1114, and create a thread for each connection when        it is established.    -   2. Send a ready message indicating available pre-allocated disk        space for the file to the sldd 1113, 1114.    -   3. Receive the file, uncompress it and save it to disk in a well        known location (that is configurable) under a numbered sub        directory based on the current date.    -   4. Acknowledge receipt of the file, close the connection and        exit the thread.        Database Insertor Daemon—sldb

The database insertor daemon 1108, 1110, running on the Log Server 1105,1106, does the following:

-   -   1. Looks up the latest directory in which the Log Collector        daemon 1107, 1109, is placing the log files.    -   2. When a new log file is found, checks to see if the contents        of the file needs to be added to the database. Some files like        the syslog files need not be processed.    -   3. Creates a thread for the file. The thread establishes a        connection to the database and inserts the contents of the log        file into the database.    -   4. Exit the thread.    -   5. The database insertor 1108, 1110, can also be run in        standalone mode. In this mode, sldb 1108, 1110, can be        configured to look for files starting from a specified sub        directory and insert them into the database.        Config File Format

The log daemons do not depend on the configuration file. All theinformation they need is hard coded or DNS based. This reduces the needto ship config files to all the servers in the network.

Command Line Options

The following command line options are supported by the daemons.

-d <donedir> sets the done directory for the distributor daemon -r<recvdir> sets the receive directory for the collector daemon anddatabase insertor daemon. -p <port num> sets the port num for thecollector or distributor daemon -i <ip> sets the default ip for sendinglog files, for the distributor daemon -m <no. of threads> maximum numberof threads for the daemon -s run in standalone mode, not as a daemon-D<debug level > sets the debug option with the level specified -Vprints the version information -v prints the CV S version information-h/? prints usage options

Apart from the above the database insertor daemon (sldb) also supportsthe following options:

-S<ddmmhhyy> date dir from which to start inserting files, default iscurrent datedir -b<subdir num> subdir number inside the startdir tostart from, default is 0 -e<end subdir> subdir at which to stopinserting files, default is to keep up with the collector daemonFile Naming Conventions

Log files are named according to the following naming convention. The_character is used as a token separator.

Message Formats

svc_svcst_server_location_network_ip_date_time(s)_time(us)_pid svcservice name (eg. http, dns, sprobe, lprobe, ...) svcst service sub type(eg. sec, min, log ) server server name (eg. server-1, server-2, ...)location location name (eg. sjc, bos,...) network network name (eg. mci,uunet, ...) ip server ip (eg. 10.10.10.12, ...) time timein secs sincethe Epoch time time in usecs pid pid (process id)

The message format used to communicate between the log distributordaemon and the log collector daemon is described below. Each messageconsists of an eight byte fixed header plus a variable size payload:

Version Opcode Info Resvd Payload Length Payload DataOpcode (1 byte)

The currently defined opcodes are:

Value Name 0 SLU_INVALID 1 SLU_FILE_READY 2 SLU_RECV_READY 3SLU_FILE_DATA 4 SLU_FILE_RECD 5 SLU_ERROR

-   Info (1 byte)-   Contains opcode specific information.-   Version Number (1 byte)-   The logging subsystem protocol version number-   Payload Length (4 bytes)-   The total length of the payload data in bytes.-   Payload-   Command specific payload data field.-   All the fields are in network byte order.-   SLU_INVALID-   A place holder to detect zero-filled or malformed messages.    SLU_FILE_READY

The log distributor daemon sends this message to the log collectordaemon after it finds a log file and connects. The expected responsefrom the log collector daemon is an SLU_RECV_READY. If there is aproblem an SLU_ERROR is returned:

File Size File Name Length File NameSLU_RECV_READY

The log collector daemon returns this message when it is ready toreceive data after a new connect.

SLU_FILE_DATA

This message is sent when the log distributor daemon is ready to send afile to the log collector daemon after the collector daemon returns theSLU_RECV_READY Message. The payload contains the compressed file data:

Compressed File Data

SLU_FILE_RECD

This message is sent when the log collector deamon has successfully recda file.

SLU_ERROR

This message is returned on any non recoverable error. The info field inthe message header contains qualifying information on the errorcondition. The following fields are valid. The connection is reset onany error condition.

Error Handling

Connect failure for distributor daemon:

In case the distributor daemon is not able to establish a connection toany of the Log Servers, the number of active threads is reduced to one.This thread keeps trying to connect to the Log Server after certain timeintervals. If a connection is established, the number of threads for thedistributor daemon is restored back to the maximum configured value.

Although the invention is described herein with reference to thepreferred embodiment, one skilled in the art will readily appreciatethat other applications may be substituted for those set forth hereinwithout departing from the spirit and scope of the present invention.Accordingly, the invention should only be limited by the Claims includedbelow.

The invention claimed is:
 1. A system, comprising: a first machineoperated by a service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor to provide a first service torequesting clients via a network interface, the first service being anyof: HTTP service, HTTPS service, and FTP service; a second machineoperated by the service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor to provide a second service torequesting clients via a network interface, the second service beingdifferent than the first service; a third machine operated by theservice provider and comprising at least one hardware microprocessorcoupled to memory storing code that is executable on the at least onehardware microprocessor to determine a specific load metric thatreflects load on the first machine for the first service, wherein thespecific load metric is of a type that is specific to the first service;the code on the third machine further being executable on the at leastone hardware microprocessor to determine a generic load metric thatreflects load on the second machine for the second service, wherein thegeneric load metric is of a type that is generic to the first and secondservices.
 2. The system of claim 1, wherein the first and secondservices are mapped to first and second hostnames, respectively, thesystem further comprising a fourth machine operated by the serviceprovider and comprising at least one hardware microprocessor coupled tomemory storing code that is executable on the at least one hardwaremicroprocessor to provide a DNS service via a network interface, the DNSservice determining a machine address to return to a requesting DNSclient, so as to cause requests for content to be made to saiddetermined machine address, wherein said determination is based at leastin part on: (i) the specific load metric, for a DNS request to resolvethe first hostname; and (ii) the generic load metric, for a DNS requestto resolve the second hostname.
 3. The system of claim 2, wherein saiddetermined machine address comprises an internet protocol (IP) address.4. The system of claim 1, wherein the specific load metric reflectsperformance of the first service as a user would experience the firstservice.
 5. The system of claim 1, wherein the specific load metriccomprises a time to retrieve a Web page using the first service.
 6. Thesystem of claim 1, wherein the generic load metric comprises any of CPUutilization and memory utilization of the second machine.
 7. The systemof claim 1, wherein the first machine and the second machine are eachone of a plurality of first machines and second machines, respectively,operated by the service provider on behalf of a plurality of customerswho have content that is delivered to clients via at least one of thefirst and second machines.
 8. The system of claim 1, wherein the firstmachine comprises memory tangibly storing code that is executable on thefirst machine's at least one hardware microprocessor to run the firstmachine as a cache server storing content for delivery to requestingclients.
 9. A system, comprising: a first machine operated by a serviceprovider and comprising at least one hardware microprocessor coupled tomemory storing code that is executable on the at least one hardwaremicroprocessor to provide a first service to requesting clients via anetwork interface, the first service being a streaming media service; asecond machine operated by the service provider and comprising at leastone hardware microprocessor coupled to memory storing code that isexecutable on the at least one hardware microprocessor to provide asecond service to requesting clients via a network interface, the secondservice being different than the first service; a third machine operatedby the service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor to determine a specific load metricthat reflects load on the first machine for the first service, whereinthe specific load metric is of a type that is specific to the firstservice; the code on the third machine further being executable on theat least one hardware microprocessor to determine a generic load metricthat reflects load on the second machine for the second service, whereinthe generic load metric is of a type that is generic to the first andsecond services.
 10. The system of claim 9, wherein the first and secondservices are mapped to first and second hostnames, respectively, thesystem further comprising a fourth machine operated by the serviceprovider and comprising at least one hardware microprocessor coupled tomemory storing code that is executable on the at least one hardwaremicroprocessor to provide a DNS service via a network interface, the DNSservice determining a machine address to return to a requesting DNSclient, so as to cause requests for content to be made to saiddetermined machine address, wherein said determination is based at leastin part on: (i) the specific load metric, for a DNS request to resolvethe first hostname; and (ii) the generic load metric, for a DNS requestto resolve the second hostname.
 11. The system of claim 10, wherein saiddetermined machine address comprises an internet protocol (IP) address.12. The system of claim 9, wherein the specific load metric reflectsperformance of the first service as a user would experience the firstservice.
 13. The system of claim 9, wherein the generic load metriccomprises any of CPU utilization and memory utilization of the secondmachine.
 14. The system of claim 9, wherein the first machine and thesecond machine are each one of a plurality of first machines and secondmachines, respectively, operated by the service provider on behalf of aplurality of customers who have content that is delivered to clients viaat least one of the first and second machines.
 15. The system of claim9, wherein the first machine comprises memory tangibly storing code thatis executable on the first machine's at least one hardwaremicroprocessor to run the first machine as a cache server storingcontent for delivery to requesting clients.
 16. A method, comprising:receiving requests from clients for a first service that comprises anyof: HTTP service, HTTPS service, and FTP service, by a first machineoperated by a service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor to provide the first service;receiving requests from clients for a second service different than thefirst service, by a second machine operated by a service provider andcomprising at least one hardware microprocessor coupled to memorystoring code that is executable on the at least one hardwaremicroprocessor to provide the second service; with a third machineoperated by the service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor, determining a specific load metricthat reflects load on the first machine for the first service, whereinthe specific load metric is of a type that is specific to the firstservice; with the third machine, determining a generic load metric thatreflects load on the second machine for the second service, wherein thegeneric load metric is of a type that is generic to the first and secondservices.
 17. The method of claim 16, further comprising: wherein thefirst and second services are mapped to first and second hostnames,respectively, the method further comprising, with a fourth machineoperated by the service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor, providing a DNS service via anetwork interface, and as part of the DNS service, determining a machineaddress to return to a requesting DNS client, so as to cause requestsfor content to be made to said determined machine address, wherein saiddetermination is based at least in part on: (i) the specific loadmetric, for a DNS request to resolve the first hostname; and (ii) thegeneric load metric, for a DNS request to resolve the second hostname.18. A method, comprising: receiving requests from clients for a firstservice that comprises a streaming media service, by a first machineoperated by a service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor to provide the first service;receiving requests from clients for a second service different than thefirst service, by a second machine operated by a service provider andcomprising at least one hardware microprocessor coupled to memorystoring code that is executable on the at least one hardwaremicroprocessor to provide the second service; with a third machineoperated by the service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor, determining a specific load metricthat reflects load on the first machine for the first service, whereinthe specific load metric is of a type that is specific to the firstservice; with the third machine, determining a generic load metric thatreflects load on the second machine for the second service, wherein thegeneric load metric is of a type that is generic to the first and secondservices.
 19. The method of claim 18, further comprising: wherein thefirst and second services are mapped to first and second hostnames,respectively, the method further comprising, with a fourth machineoperated by the service provider and comprising at least one hardwaremicroprocessor coupled to memory storing code that is executable on theat least one hardware microprocessor, providing a DNS service via anetwork interface, and as part of the DNS service, determining a machineaddress to return to a requesting DNS client, so as to cause requestsfor content to be made to said determined machine address, wherein saiddetermination is based at least in part on: (i) the specific loadmetric, for a DNS request to resolve the first hostname; and (ii) thegeneric load metric, for a DNS request to resolve the second hostname.